Login
Username:

Password:

Remember me



Lost Password?

Register now!
Main Menu
Who's Online
2 user(s) are online (1 user(s) are browsing Forum)

Members: 1
Guests: 1

mordesku, more...
   All Posts (DizzyOfCRN)


(1) 2 3 4 ... 103 »


Re: Controller

Joined:
2008/2/5 6:58
From Sunny Finland
Group:
Member
Posts: 1026
Offline
On the "A Week in AROS..." thread nikolaos wrote:

Quote:

Dizzy: That would be very welcome. Is it not just to do it if someone are interested. If it works it works. If you do it I give you 50£
Maybe others also would put some money into this.


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: 4/29 4:26
Transfer the post to other applications Transfer


Re: A week in AROS...

Joined:
2008/2/5 6:58
From Sunny Finland
Group:
Member
Posts: 1026
Offline
Quote:

nikolaos wrote:
Whow massive update :D

About this update.
New utility to allow dual analogue control gamepads to be used on Linux-hosted AROS, e.g. to play Tower57 (stegerg

What would it take for it to work on native AROS?

I'd say that some sort of new gamepad API is needed. Should not be too difficult if agreement on it's workings is achieved.

Posted on: 4/27 8:08
Transfer the post to other applications Transfer


Re: Controller

Joined:
2008/2/5 6:58
From Sunny Finland
Group:
Member
Posts: 1026
Offline
Quote:

Kalamatee wrote:
Quote:

DizzyOfCRN wrote:
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".


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:

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.



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.


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: 4/20 11:18
Transfer the post to other applications Transfer


Re: AROS64 USB storage device

Joined:
2008/2/5 6:58
From Sunny Finland
Group:
Member
Posts: 1026
Offline
Managed to get the vusbhci.device working on 64-bit linux and hosted AROS

https://youtu.be/BsEUUgSfAK0

It might be that our other drivers aren't 64-bit friendly or there is some other problem as Poseidon is happy on 64-bit hosted. (not tested much though)

Posted on: 4/20 3:41
_________________
Jyrki.J.Koivisto
Transfer the post to other applications Transfer


Re: Controller

Joined:
2008/2/5 6:58
From Sunny Finland
Group:
Member
Posts: 1026
Offline
Quote:

nikolaos wrote:
Dizzy: Daniel that did the Tower57 port added the option so we can use analogue hack. I can now use controller with all buttons and the 2 analog sticks that are essensial for that game.
It is for sure not the cleanest way to support dual analoge pads or many buttons and it would be welcome if someone did the needed code to implement this into AROS. From what I understood SDL can be used as reference since all the input, joypad code is there.


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: 4/19 23:05
Transfer the post to other applications Transfer


Re: Controller

Joined:
2008/2/5 6:58
From Sunny Finland
Group:
Member
Posts: 1026
Offline
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: 4/19 23:00
Transfer the post to other applications Transfer


Re: a more modern gcc?

Joined:
2008/2/5 6:58
From Sunny Finland
Group:
Member
Posts: 1026
Offline
Quote:

Kalamatee wrote:
Quote:

Kalamatee wrote:
Quote:

simplex wrote:
I looked up the ucontext.h source and I think maybe you meant that I should change it to struct ucontext_t. I made that change and I’'ll update the moment I know something.



no, ucontext_t should be a typedef of type struct xxxx.




I would be interested to see the contents of your ucontext.h - could you perhaps email it to me at kalamatee@gmail.com

Thanks for fixing the AROS build with newer gcc!

Here's my ucontext relevant part in sys/ucontext.h:

/* Userlevel context. */
typedef struct ucontext_t
{
unsigned long int uc_flags;
struct ucontext_t *uc_link;
stack_t uc_stack;
mcontext_t uc_mcontext;
sigset_t uc_sigmask;
struct _libc_fpstate __fpregs_mem;
} ucontext_t;

Definition is the same for __x86_64__ and !__x86_64__

[dizzy@linux include]$ grep -r "ucontext" *

asm/ucontext.h: * layout pointed by the fpstate pointer in the ucontext's sigcontext
asm/ucontext.h:#include
asm-generic/ucontext.h:struct ucontext {
asm-generic/ucontext.h: struct ucontext *uc_link;
rdma/cxgb4-abi.h:struct c4iw_alloc_ucontext_resp {
rdma/mlx5-abi.h:struct mlx5_ib_alloc_ucontext_req {
rdma/mlx5-abi.h:struct mlx5_ib_alloc_ucontext_req_v2 {
rdma/mlx5-abi.h:enum mlx5_ib_alloc_ucontext_resp_mask {
rdma/mlx5-abi.h:struct mlx5_ib_alloc_ucontext_resp {
rdma/qedr-abi.h:struct qedr_alloc_ucontext_resp {
rdma/mthca-abi.h:struct mthca_alloc_ucontext_resp {
rdma/vmw_pvrdma-abi.h:struct pvrdma_alloc_ucontext_resp {
rdma/hns-abi.h:struct hns_roce_ib_alloc_ucontext_resp {
rdma/ocrdma-abi.h:struct ocrdma_alloc_ucontext_resp {
rdma/nes-abi.h:struct nes_alloc_ucontext_req {
rdma/nes-abi.h:struct nes_alloc_ucontext_resp {
rdma/mlx4-abi.h:struct mlx4_ib_alloc_ucontext_resp_v3 {
rdma/mlx4-abi.h:struct mlx4_ib_alloc_ucontext_resp {
signal.h:/* This will define `ucontext_t' and `mcontext_t'. */
signal.h:# include
sys/ucontext.h:typedef struct ucontext_t
sys/ucontext.h: struct ucontext_t *uc_link;
sys/ucontext.h: } ucontext_t;
sys/ucontext.h:typedef struct ucontext_t
sys/ucontext.h: struct ucontext_t *uc_link;
sys/ucontext.h: } ucontext_t;
sys/ucontext.h:#endif /* sys/ucontext.h */
ucontext.h:#include
ucontext.h:extern int getcontext (ucontext_t *__ucp) __THROWNL;
ucontext.h:extern int setcontext (const ucontext_t *__ucp) __THROWNL;
ucontext.h:extern int swapcontext (ucontext_t *__restrict __oucp,
ucontext.h: const ucontext_t *__restrict __ucp) __THROWNL;
ucontext.h:extern void makecontext (ucontext_t *__ucp, void (*__func) (void),
ucontext.h:#endif /* ucontext.h */

Posted on: 4/19 22:48
Transfer the post to other applications Transfer


Re: Controller

Joined:
2008/2/5 6:58
From Sunny Finland
Group:
Member
Posts: 1026
Offline
HID class patches the lowlevel library and from Trident one can map the joystick movements to it, I think...

https://youtu.be/OKaW19B7wnc

Found also this, http://aros-exec.org/modules/newbb/vi ... t_id=57903#forumpost57903

Nothing happened since the first post on 2011/7/26 :)

Posted on: 4/19 6:58
Transfer the post to other applications Transfer


Re: AROS64 USB storage device

Joined:
2008/2/5 6:58
From Sunny Finland
Group:
Member
Posts: 1026
Offline
Well, this is interesting...

I littered do_libusb_ctrl_transfer(struct IOUsbHWReq *ioreq) with debug statements and suddenly it started to work again... (some devices that don't bind with anything are recognized, some are not)

Something is asking the device something before it is ready to answer... This might be one reason why the usb stack works for someone and not for the other.

EDIT:

Doing this request takes a very long time to complete

[VUSBHCI2.00] do_libusb_ctrl_transfer: ioreq->iouh_SetupData.bmRequestType 80
[VUSBHCI2.00] do_libusb_ctrl_transfer: ioreq->iouh_SetupData.bRequest 6
[VUSBHCI2.00] do_libusb_ctrl_transfer: ioreq->iouh_SetupData.wValue 301
[VUSBHCI2.00] do_libusb_ctrl_transfer: ioreq->iouh_SetupData.wIndex 409
[VUSBHCI2.00] do_libusb_ctrl_transfer: ioreq->iouh_SetupData.wLength 2
[VUSBHCI2.00] do_libusb_ctrl_transfer: ioreq->iouh_Length 2
[VUSBHCI2.00] do_libusb_ctrl_transfer: Done!

This would be the get descriptor request for language id or something from the top of my head...

EDIT: This might just be a problem on my setup and the vusbhci.device that's the culprit. Don't really remember where I left it...

EDIT: I remember doing something to the vusbhci.device how it handles usb2.0 and usb3.0 devices plugged into usb2.0 host or usb3.0 host, maybe my problems are due to just that.

EDIT: My hosted AROS build is based upon ABIv1 as is the AROS 64-bit (If I have understod it correctly... :) ) and my Linux distribution is also 64-bit. That's the relevance with Nikolaos problems and mine.

EDIT: Poseidon is really anal about the debugs, too much and it won't work and too little seems to be the same. Something ain't right with it...

Posted on: 4/17 4:18

Edited by DizzyOfCRN on 2018/4/17 5:16:42
Edited by DizzyOfCRN on 2018/4/17 6:11:49
Edited by DizzyOfCRN on 2018/4/17 10:19:50
Edited by DizzyOfCRN on 2018/4/17 10:25:07
Edited by DizzyOfCRN on 2018/4/17 10:30:58
Edited by DizzyOfCRN on 2018/4/17 10:41:27
_________________
Jyrki.J.Koivisto
Transfer the post to other applications Transfer


Re: AROS64 USB storage device

Joined:
2008/2/5 6:58
From Sunny Finland
Group:
Member
Posts: 1026
Offline
Just managed to compile the hosted version of AROS on my Fedora 27 installation. Had to make an older version of gcc and compile AROS hosted with that. AROS build system doesn't like the gcc 7.3.0 as bundled with Fedora 27 or vice versa...

massstorage.class doesn't work with my hosted build and vusbhci.device either anymore... Something has changed...

I tried a fat formatted usb drive and it seems to hang right after filtering out setaddress. Those devices that don't bind with any classes are recognized and AROS does not hang.

Posted on: 4/17 3:42
Transfer the post to other applications Transfer



 Top
(1) 2 3 4 ... 103 »




Search
Top Posters
1 paolone
paolone
4405
2 magorium
magorium
4095
3 nikolaos
nikolaos
3964
4 phoenixkonsole
phoenixkonsole
3903
5 deadwood
deadwood
2917
6 ncafferkey
ncafferkey
2778
7 mazze
mazze
2221
8 Kalamatee
Kalamatee
2139
9 clusteruk
clusteruk
2112
10 damocles
damocles
1789
© 2004-2018 AROS Exec