[Finished] [MP1-4795] Add keyboard support to HID handler (5 Viewers)

[Stéphane Lenclud]

It's optionally configurable in the plugin though but agree it's far from perfect, like you said best solution would be published actions by plugins so that the HID handlers can read those out and map

I might be working on that at some point.

 

[Rick164]

Nice

Some plugins might break with this change so will make a small keyboard wrapper class for SharpLibHid which they can then optionally use as there's no example documentation for it judging by their project page.

 

[Stéphane Lenclud]

no example documentation

See: https://sharplibhid.codeplex.com/SourceControl/latest#MainForm.cs
You could checkout the code and run that HID Demo if you wanted to set a few breakpoints to see how that works.
I'm the owner of that project.

You can only have one WM_INPUT registration per process I believe. So you need to hook into the WndProc from MP and call libhid.ProcessInput from there.
Then you should get events providing that you registered to OnHidEvent.

 

[Rick164]

Some minor issues so far with showing dialogs when using WM_INPUT, when setting a keyChar to show a Mediaportal keyboard dialog (for search) there's a 5-10s delay before it allows for input.
Will try the subscribe to WndProc of MP instead and see if that helps

 

[Stéphane Lenclud]

there's a 5-10s delay before it allows for input

That should not be. Sounds like you are getting stuck on a mutex for some reason.
I tried yesterday the Auto3D plugin and that works nicely. Though I think you could make the code even simpler since there are left over from not using SharpLibHid.
Checkout the Auto3D source code on GitHub specifically that HIDInput.cs file.
Basically it registers for Window Messages through Application.AddMessageFilter.
Then it uses SharpLibHid when in Configure but not when in MediaPortal.
In theory you should be able to use SharpLibHid in both cases.
The difference is that you need to register devices only from Configure and not from MediaPortal.

 

[Rick164]

Had some time and tried to implement that in the AudioSwitcher but it adds some complexity and additional libraries where as if it were to be built-in to Mediaportal would make it re-usable for all plugins.
Any possibility for the new HID handler could forward it to the OnMessage event that is currently in place for legacy support?

It would not provide any modifier key readouts as that is currently not possible with OnMessage event but wouldn't break any plugins or require updating them which for some might not be possible due to the developers no longer being active
Other solution might be to expand the OnMessage event to include more information like the modifier keys if possible or a new one to subscribe to which offers that.

 

[Stéphane Lenclud]

Any possibility for the new HID handler could forward it to the OnMessage event that is currently in place for legacy support?

It sure is possible but it sounds like a major pain. If a user has a dependency on a plug-in that's not being supported anymore she can stick to an older version of MP1.

Had some time and tried to implement that in the AudioSwitcher

Could you get it to work? You would need to use the same SharpLibHid version that's used by the MP version you are targeting.
MP1.15 is using SharpLibHid v1.3.1.

if it were to be built-in to Mediaportal would make it re-usable for all plugins.

It does not need to. However ideally plug-in should not have to deal with key handling themselves.
Here is the way it should be done:

• Have a framework that let plug-ins publish their own actions.
• Plug-ins actions can then be mapped to keys much like built-in actions.
• Plug-ins can then handle actions rather than keys.

Until this is done however you should use SharpLibHid.

 

[Rick164]

Believe when I tried it Mediaportal it would still receive the key command as well as it had no way of cancelling that out, will re-check with latest build and test compatibility as MyAnime3 now uses the OnMessage event as well for its live filtering :

https://github.com/japanesemediaman...er/MyAnimePlugin3/Windows/MainWindow.cs#L2441

If this makes the cut for 1.16 will it still allow for the above message handling or does it need to use sharplibhid (i.e. no backwards compatibility option) ?
As an extra dependency for plugins this might be small problem if you have multiple plugins using it at some point (overwriting each others)

 

[Rick164]

Few things I noticed setup wise:

- No keyboard HID by default

You don't get HID keyboard on by default and classic preset only includes gamepad / mce.

Before the keyboard bindings were present by default, while the old area (General -> Keys and sounds) is there it might be a surprise for some to find their default key bindings are no longer working.
Option might be to keep HID keyboard on by default and set it either full or another which includes the default keyboard bindings.

- Option to capture key input

Old keyboard area had the option to capture a key as this made it easier to setup and especially for non-standard keys (< and >) it might not be possible to find them because of obscure name or just not in the default list.

- Backwards compatibility with plugins

Used MyAnime3 as a test here and indeed no longer works there to capture key input like before with the built-in Mediaportal function, the issue we talked about before.

This is something we definitely need to test with a lot more plugins which rely on this as I'm gonna give SharpHID a go for Myanime 3 but probably won't be an option for every plugin that uses these events

For AtmoLight this will only require a small documentation update but other than that it worked as expected when mapping keys to its teletext colors.

 

[Sebastiii]

Thanks for the testing

I would say that the branch is not fully ready for master then but keep up the good work