http://www.aros.org/ logo
Join Slack
Powered by
Bad to see :upside_down_face:
# aros
c
Bad to see 🙃
👍 3
k
I think you want to try and style the UI similar to Trident prefs for poseidon - with hardware/devices/classes listed - and your scan code moved into a pop up to add a new device
c
I used the Wi-Fi layout as basis. As i said I am wainting @Terminills guidance for the integretion, this is a kind of self contained app. I dont fully understand what you mean about the poseidon integration (i never saw the poisedon prefs myself), but it's more an ux thing. As i said before i just want to say hi to the hardware so i could keep evolving the protocolo/mechanisms that doesnt really rely on those integrations.
k
it needs to be implemented in a way similar to poseidon or it wont work
c
How is that?
k
so you would do well to look into how that works
because it is fundamentally similar in concept.
you need an api to let classes that handle devices bind to things you scan for
c
Yes and no, it is conceptually a wireless serial, but no, they are not the same from an ux pov
k
no thats just how it communicates - how the overall stakc works is similar to usb
thats irrelevant to how the whole picture fits together
and Term will only tell you the things I have told him already
c
I have saw some bridge allready in place and did the design to use it
I have even asked you if that design was correct, i did used it as basis.
k
I have told you how it needs to be and you are dismissing it lol
c
No, i think we are talking about diferent things
k
it fundamentally needs to work similar to poseidon
c
Enumarating the 2 stages bus?
Detecting connection and disconection?
k
you need an api to (a) let hardware drivers connect to, (b) let devices be expressed via, and (c) let classes bind to those devices
so t needs to manage those things, and the UI needs to expose those things
poseidon basically does this already for usb
c
I will dig into it to get some insight
k
when a radio is registered it needs to spawn a task that is basically an instance of the bluetooth stack
(which, again, is how poseidon works with usb hardware)
c
Atm i was thinking more about reverse connection, auto connection, filter dual devices etc …
t
Without a proper API it will just happily sit there and do nothing. :)
k
there is a much bigger picture than just driving a radio to find devices
you need to provide the infrastructure for it all to comminicate and work in a friendly manner
c
Hid wiring you mean?
k
and thats what posiedon is an almost identical template for
c
Both USB and bt pool the same hid like for a keyboard
k
no coolcat, how they all speak to each other
how your classes speak to the devices over the radio
how the devices are managed and bound to classes
you need to think about these things before you can make it an actual usable thing
you need to expose a library like poseidon.library to "glue" all this together
and an app like Trident to let users manage it properly
c
I have draw something but it's not like you said. As i said i will dig into it. I came from a cherryusb and btstack experience and those was not the same thing
What i saw so far was a bridge between poseidon and bt for bt dongles support
k
there is a lot more to it than you think
theres a reason poseidon is implemented the way it is
t
That's just how the dongle connects to aros
c
As i said I used both, btstack and cherryusb. I did it.
k
you dont know if the thing speaking to your class/device is a task or process, etc - so you need to use something like a device api like poseidon to facilitate transmitting data between classes and devices over the radio
how they work is largely irrelevant to how things need to work on amigaos
or amigaos like os'es
c
I could only tell when i dig into it … as far as i got those are not as imbricated as you metioned, but if it is we will do like that
The points that i am doing are bt specs
k
the specs are a tiny part of the big picture
c
Thing that is from bt docs of how bt works
Yes, but that doesnt change
k
if you dont look into how it all fits together in an amigaos like system - you are not going to get anywhere usable
t
USB and BT would not pool the same HID Poseidon doesn't have a Bluetooth stack and has a communication API. A Bluetooth stack would have its own classes and glue.
k
@Terminills exactly
c
If you put one keyboard into usb and another on bt how could it reach the input without a poll to not mess it all?
k
it would need to implement its own stack almost identical to poseidon, to manage the radios, connected devices, and classes that let the devices actually work.
it needs a task to manage the "stack" instance for a radio
c
Yes, it has
k
not just any old task coolcat, one spawned by the api against any bound radio
that handles comminication to devices and classes via the api it exposes in the shared library
c
Sure kal, that is what is meant
Applications and AROS classes | v bluetooth.library | v Bluetooth Manager Task | v Portable protocol core | v Abstract HCI transport interface | +-- Poseidon USB Bluetooth class +-- UART transport +-- virtual controller (testing)
k
yes similar to that
but there is more to it than a simple flow chart like that
c
Its exactly what i am doing
Ok, as i said, i need to get there first
Atm i was just saing hi to the hardware
k
and that is exactly why I said you need to look at how poseidon works or you are not going to get anywhere
c
And still there is a lot to do in that layer
k
or just reinvent the wheel to do exactly the same thing it already does.
c
I said that i will look 🙃
But what is missing are things in another layer, i am not there yet
Infact i was waiting @Terminills to this specific part
What i want to have is reverse conection, persist connections etc …
k
then look into how trident works with poseidon 🤦‍♂️
c
I have a mouse with 3 channels and it need this kind of stuff to change between devices
k
im not sure what you dont get - you need these things to povide the layer you say you are missing
c
I will
Yes, i am missing 2 layers or more atm lol
I dont have sound support yet, for example
k
you are missing the whole abstraction and api for how those pieces communicate in an amigaos like system
c
(That is a protocol)
Its different layers kal, and yes, those was exactly where terminils was, at least from what i understood, enters in
k
no thats the problem and you are naive to think it is just a matter of layers
adding protocols to the library isnt going to fix it
your stack will break when things you didnt think about, try to interact with the devices you expose (e.g. filesystems, audio devices, etc)
c
Its not broked cause i am not there yet …
The protocols are what the stack can support, it is not meant to do what you are describing
k
yes it is lol
in an amigaos environement, thats exactly what it is meant to do
c
Imagine usb protocols like hid and msc
The support for those are completelly independent. You can implement one or another, or both, in one layer. And how those are integrated into the big picture is another layer
k
thats irrelevant - you need to define an api to communicate to them "that works in an amigas like enviroenemt" - and just calling api functions from bluez isnt going to cut it
c
Sure, i just didnt got there yet…
And I thought that was exactly what terminills was working on 🙃
Erverything i am doing are core from the bt specs, nothing more nothing less
Sure it will need to be integrated to the os (and yes i will look over poseidon/trident if i need to do this layer)
There is nothing amiga specific yet
That are the work so far, protocols. You need those if you want to support each.
Lets say that is the middle layer (the stack)
Now i did said hi to the hw (that is the low layer)
And i think you are talking about the high layer
(Vendor init is not a protocol 😬)
k
no coolcat
im talking about how those things all interact in a way that works in an operating system like amigaos
the complexity of what happens when a task wants to do something with a device over your radio - and what the communication from the task to the radio (via the classes for whatever it is you are connecting to)
not just the protocol, but the system level interactions, like having to trigger interupts, and wait for responses and how this is all handled
making a class speak to a device is relatively easy
doing it in a way that can be used by things in the operating system, isnt necessarily as easy or straight forward
especially not without it all just breaking
4 Views
Open in Slack
PreviousNext
Powered by