•   
  • 1
  • 3
  • 4
  • 5(current)
  • 6
  • 7
  • 26
  •   
Input
#61
looking forward to test it, keep going! *drooling* Wink
Wetek Play: LibreELEC 9.0.x as TVH-server --- Odroid N2: CoreELEC 19.1 --- Orbsmart 500 Android 19.1 as Online-radio/TV in the kitchen
Reply
#62
(2015-01-12, 21:08)garbear Wrote:
(2015-01-11, 17:35)RockerC Wrote: Regardless, you should try to checkout Ignition, it have a dead simple interface for setting up your gamepad or joystick for all the emulators

https://www.kickstarter.com/projects/171...-raspberr/
I've heard great things about this project, but it looks like it's only available to backers right now? Does anyone have a link for research purposes?
I'm sure that that the developer of Ignition, Alex Stubbs, would be more than happy to give a reputable developer like yourself access to copies of it if you mail him

[email protected] looks to be his mail address according to his website at http://www.alexstubbs.com

Alex have promised that Ignition will also be released under an open source license as soon as it is out of the Alpha and Beta stages.

Even though his code might not help your cause for Kodi, his interface design in Ignition could probably give you some great idea on how to implement the GUI parts
Reply
#63
@garbear, have you looked anything at the design of Libinput?

http://www.freedesktop.org/wiki/Software/libinput/

http://www.freedesktop.org/wiki/Software...evelopers/
Reply
#64
(2015-01-14, 09:30)RockerC Wrote: I'm sure that that the developer of Ignition, Alex Stubbs, would be more than happy to give a reputable developer like yourself access to copies of it if you mail him

[email protected] looks to be his mail address according to his website at http://www.alexstubbs.com

Alex have promised that Ignition will also be released under an open source license as soon as it is out of the Alpha and Beta stages.

Even though his code might not help your cause for Kodi, his interface design in Ignition could probably give you some great idea on how to implement the GUI parts

Cool, I'm out of time this break so next time I'm able to sink a week or two into input I'll shoot him an email.

(2015-01-15, 19:44)Hedda Wrote: @garbear, have you looked anything at the design of Libinput?

http://www.freedesktop.org/wiki/Software/libinput/

http://www.freedesktop.org/wiki/Software...evelopers/

nice, maybe someone will write a libinput backend. on linux we already have SDL and the raw linux joystick api, so adding a libinput backend should be straight-forward. our joystick engine supports multiple joystick APIs at the same time, so you can mix DirectX and XInput joysticks on windows, or SDL/joystick api/libinput on linux and choose an API at run-time.
Reply
#65
i'; be following this project
Reply
#66
(2015-01-09, 01:10)garbear Wrote: If you want to help out, post your craziest ideas here or in the Input thead. Brainstorming with you guys has been invaluable, so I'm always open for ideas/feedback.

When recognizing Wii Remotes, make IR work as mouse input.
Reply
#67
or head tracking input

Reply
#68
Maybe try to copy the input to output translator code from the "Kade" open source adapter device project?

https://www.kickstarter.com/projects/kad...rs-and-con

It sounds as if this project already have mapped the schemes needed to translate controller input/output.

https://github.com/kadevice/KADE

Also their "KADE Loader" is an open source GUI software for creating or modifying custom mappings.

http://kadevice.com and http://kadevice.com/forum

Image

Image

Image
Reply
#69
I wonder if this thread efforts could converge with this other
http://forum.kodi.tv/showthread.php?tid=168767

Graphical configuration of gamepads, joysticks, wiipads, kincts... Why not remotes?
Reply
#70
Here is configuration GUI draft 2

Image

I've eliminated the need to store button names, colors, symbol colors (omg) and SVG icons. When you press a button or move an analog stick the corresponding motion shows up on the controller in the GUI. This way buttons can be quickly identified without putting even more data onto the screen.

In the artwork, you can see that the A button is being pressed, along with left shoulder and the up-right diagonal on the dpad. The right analog stick is centered and the left is in motion. A little black cursor shows up and tracks the position of the analog stick.

It still needs a "clear" or "reset" button. Also a way to un-map individual buttons. Maybe by holding?

I would also like a way to see unmapped buttons/axes. Maybe an area of the screen that shows the state of unmapped buttons/axes?
Reply
#71
I've had people ask me how to install this Genesis plugin they heard about which shows in your screenshot ...
(yes i know that is Sega Genesis)
Reply
#72
How likely is this controller stuff to make it into the next stable release? It would be of great benefit just for using controllers to control kodi and its one piece of the puzzle completed then as well.
Reply
#73
(2015-01-22, 15:28)Kib Wrote: I've had people ask me how to install this Genesis plugin they heard about which shows in your screenshot ...
(yes i know that is Sega Genesis)

Haha tell them first rule of RetroPlayer is you can't talk about RetroPlayer. But on the bright side maybe Plex can do it... Wink

(2015-01-22, 18:36)OmniBlade Wrote: How likely is this controller stuff to make it into the next stable release? It would be of great benefit just for using controllers to control kodi and its one piece of the puzzle completed then as well.

Next to zero, but this is a good thing. We're trying to shorten our release cycle to 6-8 months, so by focusing on stability and performance this next "I" release means we'll have an even more solid base to work off of.

Fortunately, this controller feature is entirely independent of RetroPlayer ATM, so merging the controller work can happen before the monstrosity of the RetroPlayer patch is finished.
Reply
#74
(2015-01-20, 14:25)Hedda Wrote: Maybe try to copy the input to output translator code from the "Kade" open source adapter device project?

Image

This KADE thing is fricken sweet. These kind of hardware mods are exactly what I hope to support through peripheral add-ons.

In this case, the KADE can emulate a "USB/HID Joystick Encoder" you'll see in your quote, which should mean it'll get picked up by the operating system's driver and then detected by Kodi.

However, if the generic USB/HID driver fails, KADE (or anyone else) can write a joystick add-on with a few lines of C++ so the KADE adapter works in Kodi with any driver (or even no driver at all).
Reply
#75
Update on input

360-like controllers on Windows are now (finally) capable of controlling Kodi. this means that, a few bugs aside. work can now begin on the configuration GUI and button mapper backend.

getting to this point has been way more work than I anticipated. for those interested, i'll outline the lifetime of a button press, from the physical press to Kodi's event handler
  • User presses or releases button, or moves an analog stick/trigger
  • Peripheral add-on samples the driver's state and emits events for button, hat and axis changes
  • Events are translated into C structs
  • Structs are handed across the DLL boundary
  • Structs are converted back into events
  • Events (still raw driver data) are mapped to physical joystick features (buttons, triggers, analog sticks) using data provided by the button mapper backend (e.g., multiple axis events are combined to form a single analog stick event)
  • Physical features are translated into Kodi button IDs corresponding to joystick.xml entries
  • Button IDs are dispatched to Kodi's event handler

From there, existing code uses joystick.xml to translate the button IDs to Kodi actions (like Select, Back, or ActivateWindow(HOME)) depending on the active window

how many internal representations do events take on? my head hurts, you do the math. Introducing C structs has allowed for peripheral add-ons, which isolate platforms-specific code and allow for DIY hardware, at the cost of a few thousand lines of code. This part of my input work is 100% done.

Joystick features are also new. Driver events used to be translated directly into button IDs. Injecting this intermediary abstraction is the meat of this project. it allows for a natural, intuitive implementation of a configuration GUI. Gestures (like rotating the analog sticks) can be built on top of it someday. This layer is now fully in place, give or take a few bugs, except for the button mapper and configuration GUI.

The Windows driver for 360-like controllers is kind enough to map buttons for us. No need for a controller database or any configuration. This is why these controllers are currently working.

What's next?

All we need now is a way to configure buttons, and a way to store these configurations. I think it makes sense to build the configuration GUI first. A database isn't much use if you can't populate it with data.
Reply
  •   
  • 1
  • 3
  • 4
  • 5(current)
  • 6
  • 7
  • 26
  •   



Logout Mark Read Team Forum Stats Members Help
Input3
This forum uses Lukasz Tkacz MyBB addons.