typos in keymaps/joystick.xml

[frostworx]

hi!

found some other typos in keymaps/joystick.xml

--- system/keymaps/joystick.xml 2015-01-11 10:18:30.000000000 +0100
+++ system/keymaps/joystick.xml 2015-01-11 10:21:32.000000000 +0100
@@ -57,7 +57,7 @@

•  <rsick></rstick>
  

•  <rstick></rstick>
  

  
  ActivateWindow(Home)
  
  @@ -67,14 +67,14 @@
  Left
  Right

•  <left_joy_up>Up</up>
  

•  <left_joy_down>Down</down>
  

•  <left_joy_left>Left</left>
  

•  <left_joy_right>Right</right>
  

•  <right_joy_up>Up</up>
  

•  <right_joy_down>Down</down>
  

•  <right_joy_left>Left</left>
  

•  <right_joy_right>Right</right>
  

•  <left_joy_up>Up</left_joy_up>
  

•  <left_joy_down>Down</left_joy_down>
  

•  <left_joy_left>Left</left_joy_left>
  

•  <left_joy_right>Right</left_joy_right>
  

•  <right_joy_up>Up</right_joy_up>
  

•  <right_joy_down>Down</right_joy_down>
  

•  <right_joy_left>Left</right_joy_left>
  

•  <right_joy_right>Right</right_joy_right>
  

====

if it is not too much requested would you please update to kodi-14.0 stable or even git master?
thank you very much for your GREAT work! :}

[garbear]

hi frostworx, the current joystick.xml is just a demo that I created before I even started on this project. at some point we need a completed joystick.xml to load, however. do you want to finish joystick.xml? it should look more like this than the current revision.

[a1rwulf]

hey garbear,
I fetched your branch and compiled successfully.
I get bad status when the addon tries to load - may I ask in what status this is right now - is it supposed to work?

[garbear]

I haven't synced the API so some functions are missing. Once the API is
synced, the functions can be stubbed and it should load.

Current status: Joystick add-on scans, Kodi creates joysticks from scan
results, Joystick add-on emits events, Kodi hands events to joystick
objects, and that's where things are at so far.

To get joysticks working completely, the add-on needs to implement the
joystick button mapping functions, then Kodi needs to handle the mapped
buttons by sending the action to a game add-on's "port" or translating the
button to a Kodi action. joysticks.xml needs to be loaded for the last part
to happen.

So not as far along as I'd like, but the API is mostly finished now so it
should just be a process of implementing the remaining parts on both sides.

On Mon, Jan 12, 2015 at 1:10 AM, Wolfgang Haupt notifications@github.com
wrote:

hey garbear,
I fetched your branch and compiled successfully.
I get bad status when the addon tries to load - may I ask in what status
this is right now - is it supposed to work?

—
Reply to this email directly or view it on GitHub
#20 (comment).

[a1rwulf]

Sounds quite awesome to me :-)
How do you plan to proceed?
For my libretro-gl stuff it would be nice if we can get the retrocode in too, because we need working analog axis for most n64 games.

[garbear]

I guess just implement the remaining parts. button mapping, joystick.xml
loading and a port manager so joysticks can be assigned to game ports. not
sure how much work this'll be. my time for retroplayer might be limited
over the next three weeks, but hopefully I can chip away at the remaining
parts

how goes the libretro-gl work?
On Jan 12, 2015 12:49 PM, "Wolfgang Haupt" notifications@github.com wrote:

Sounds quite awesome to me :-)
How do you plan to proceed?
For my libretro-gl stuff it would be nice if we can get the retrocode in
too, because we need working analog axis for most n64 games.

—
Reply to this email directly or view it on GitHub
#20 (comment).

[a1rwulf]

I did some further research regarding the OpenGL and OpenGL ES stuff needed and had a few mails with fernetmenta about EGL and OpenGL which seems to replace GLX some time.
Despite educating myself and doing research I had no time to code something.
Don't know if I already said this, but when I use the glide64 gfx plugin mario kart seems to work fine, while ssb and mario64 works only with the "rice" gfx plugin. Not sure if it is plugin related or if my code is responsible for this.
Due to the need for analog axis I could not really play anything right now.
To get a better feeling it would be nice to have some input to actually play games :)
That's why I think I may help you with getting input ready.
I think what I need to get more chances to test libretro-gl is following:

• ability to give inputs into a game
• retroplayer code rebased onto this branch
• i can then rebase my branch on top of yours

What do you think about this?

[garbear]

Back in the xbox days, there were a few N64 emus available but by far the best was Surreal64. It had a ROM database that said not only which graphics plugins worked best with each rom, but also which emulator worked best. Surreal64 shipped with 3 different emus (project64 and two others) and would load a different one for each ROM depending on which was most compatible.

Right now my joysticks branch is based off Helix, but it doesn't have any retroplayer code. The most recent retroplayer branch is 13.2 (repo default). I wanted to finish joysticks first so I didn't have to rebase unnecessary code. If you need helix in the meantime, though, I can rebase on helix with no joysticks code.

[a1rwulf]

I think it's by far more valuable to have proper input before doing the rebase. No need to hurry for the rebase now, I'll have a look at the joystick code in the meantime. Maybe I can chime in and help with something til we have a version with proper input and retroplayer code. From there I will continue with the libretro-gl stuff.

[garbear]

yea, input was pretty high priority for me this break... i was hoping to get it working before my break ends, but ended up re-writing the api too many times as my understanding of the input problem deepened. at least now the api should be 99% finalized (maybe some tweaks to the button mapping stuff).

input is easily the most boring part of this project (that's why I've put it off for almost 2 years now), but someone's gotta do it :/ if you do check it out, i'll understand if you get bored and move on to greener pastures full of GL adventures

[a1rwulf]

I understand. If I can figure out how the code works and how to get the addon loaded on my system I would be glad to take part of the pain away from you.
In the meantime I bought a book about OpenGL ES to get a better knowledge of the gl stuff. I'll be on 2 short snowboarding trips in the next 2 weeks, si my time will be limited too, just for your information.

[a1rwulf]

hey, had a quick look at your joystick code - impressive ;)
looks well structured and I really like your style of coding this.
you said it does already scan for joysticks - how can i trigger a scan?
i always get following logs when kodi starts:

19:57:36 T:139648533960768   DEBUG: ADDON: Dll Initializing - Kodi Joystick Library
19:57:36 T:139648533960768   DEBUG: SECTION:LoadDLL(/home/airwolf/devel/xbmc/addons/peripheral.joystick/Kodi_Joystick.so)
19:57:36 T:139648533960768   DEBUG: Loading: /home/airwolf/devel/xbmc/addons/peripheral.joystick/Kodi_Joystick.so
19:57:36 T:139648533960768   DEBUG: AddOnLog: Kodi Joystick Library: Log pipe set to "addon" from "console" at level "debug"
19:57:36 T:139648533960768   ERROR: ADDON: Dll Kodi Joystick Library - Client returned bad status (6) from Create and is not usable
19:57:36 T:139648533960768    INFO: Called Add-on status handler for '6' of clientName:Kodi Joystick Library, clientID:peripheral.joystick (same Thread=no)
19:57:36 T:139648533960768   DEBUG: PERIPHERAL - Destroy - destroying peripheral add-on 'Kodi Joystick Library'

[garbear]

error code 6 is ADDON_STATUS_PERMANENT_FAILURE - probably a missing symbol, I didn't sync the peripherals API to the add-on yet so some API headers in https://github.com/garbear/xbmc-peripheral-addons/tree/master/xbmc may be out of sync.

running make sync in the peripheral-addons folder under the root dir should sync the API files, but the sync script is possibly old/outdated so it might not work - nothing a little manual copy-paste can't fix.

the add-on is loaded on the first joystick scan, and joystick scans happen whenever a peripheral scan is launched from CPeripherals::TriggerDeviceScan(). This is first run on Kodi startup when peripherals are initialized in CApplication::Create(). however, some stuff isn't fully initialized at this time, so be aware that the first scan might fail for this reason.

joystick events are processed every frame when FrameMove() invokes this code (which should probably go somewhere else, but I didn't know where to stick it)

[garbear]

I fixed the sync script and synced the API (https://github.com/garbear/xbmc-peripheral-addons/commits/master), still untested but all symbols should resolve now

[a1rwulf]

Thanks a lot - will check it out :)

[garbear]

i pushed some fixes to xbmc.git and xbmc-peripheral-addons.git

confirmed that joysticks scan and report events in Windows with a 360 controller. at this point, event processing fails because the button mapper isn't implemented: https://github.com/garbear/xbmc-peripheral-addons/blob/91757fa/addons/peripheral.joystick/src/addon.cpp#L206

[a1rwulf]

hi, thank you very much. It does indeed scan now, I'll have a look into the linux udev scan as my 360 controller is not detected correctly. once I fixed this I'll open a PR if it is a code issue.

[a1rwulf]

hi garbear,
just saw you're pushing really hard :)
I wasn't that productive due to my "normal" work etc. - but I debugged into why my addon always exits with PERMANENT_FAILURE - it seems nothing of the following is defined:

#if defined(HAVE_DIRECT_INPUT)
  m_interfaces.push_back(new CJoystickInterfaceDirectInput);
#endif        
#if defined(HAVE_XINPUT)
  m_interfaces.push_back(new CJoystickInterfaceXInput);
#endif        
#if defined(HAVE_LINUX_JOYSTICK)   
  m_interfaces.push_back(new CJoystickInterfaceLinux);
#endif      
#if defined(HAVE_SDL)
  m_interfaces.push_back(new CJoystickInterfaceSDL);
#endif 

Do I need to give some additional params into the peripheral_addon, or should those be set when I run bootstrap and configure on Kodi side?
When I look into config.log on kodi HAVE_SDL=1 but grep does not find a match in config.log of the peripheral_addon repo.

[garbear]

these HAVE_X vars should be set by the build system when it detects SDL or <linux/joystick.h>. I just copied the build system from xbmc-pvr-addons so i don't really have any idea what's going on.

anyways, that's getting ripped out. there's a big push now to port PVR add-ons over to the new binary add-ons system. I am trying (unsuccessfully) to move peripheral.joystick over to this system with assistance from spiff here. If you have any experience with cmake i'd appreciate some help as I'm by no means a master.

[garbear]

check out https://dolphin-emu.org/blog/2015/01/25/making-developers-more-productive-dolphin-development-infrastructure/

rather overblown for this project, but it'd be cool to run automated tests on your N64 work in the cloud. a good learning project, for sure

I tried porting the add-on to our CMake binary add-ons build system. it didn't work too well, the cmake stuff is still in its infancy. I tried to solve the HAVE_X problem in garbear/peripheral.joystick@d361b63 but screwed up the variable names ;)

I'm going to stick with the old pvr-style build system until xbmc#6227 is merged. Then I'll probably rebase on master and move everything over to cmake. in the meantime, i'll probably hack around the HAVE_X problem by hard-coding the vars in the Makefile on linux.

[garbear]

@a1rwulf fixed your problem in the old buildsystem (garbear/peripheral.joystick@1dea427)

I also made SDL and linux joysticks mutually exclusive (garbear/peripheral.joystick@12048b7). I defaulted to preferring linux joysticks and dropping back to SDL. Can you think of any reason to put SDL first, or possibly a reason to select the joystick API dynamically at runtime depending on the device?

[a1rwulf]

@garbear wow thanks a lot. I'll try to have a look at it within the next few days. I'd also like to have a look into the cmake thing, but I lost track over the last days.
Automated tests for N64 emulation sounds interesting too - will also try to have a look at it :)

[a1rwulf]

hi garrett,
i just compiled and it seems to work. I have to fix some crashes now :)
I'm not an input expert but I don't feel like it is necessary to put SDL first nor a reason to select the API dynamically. But let's see how the linux joysticks work out.
Thanks a lot for your effort helping me to get it run.

[a1rwulf]

hi,
thanks for merging my PR into your peripheral repo.
Is the new KODI branch joysticks-joystick.xml the attempt to glue the peripheral addons together with KODI Input?
Anything I can help with in the meantime?

[garbear]

the new branch finally connects the add-on to Kodi input (for buttons, at least). I tested under XInput because the button map is trivial.

digital buttons work as they should, but after a few presses something deadlocks and Kodi freezes. not sure if this is related to the joystick work or my workspace is just screwed up

now that we have barebones functionality on windows you could try getting it to work on linux. until we gather button map data, you'll have to hardcode the button map like XInput, or write a simple loader for the SDL game controller DB

[garbear]

k, work in the temp branch has been moved to the main joysticks branch

I added another layer of abstraction. the current scheme looks like this:

• Input Handler uses the button map to translate raw input to joystick features
• Feature Handler translates joystick features to Kodi keypresses
• Action Handler dispatches keypresses to Kodi's event handler

I worry that we use too many layers of abstraction. processing joystick input has become quite complex. however, my motivation for the middle layer, resolving physical joystick features, will enable a natural, intuitive configuration GUI implementation. so perhaps this complexity is justified

[garbear]

I outlined the remaining work here http://forum.kodi.tv/showthread.php?tid=211138&pid=1917398#pid1917398

[a1rwulf]

Thx for the update. I'm not 100% sure if I understand everything you mentioned right away - but I'll try to get something running on linux :)

[a1rwulf]

I PR'ed into your XBMC and peripheral.addon work. With those changes the joystick works at least for digital button.
Changed joystick.xml to be able to use the left analog stick for up/down/left/right, but it doesn't work that well yet.

[garbear]

Closing, issue is obsolete