Auto3D plugin for MediaPortal 1.2 - 1.12 (GUI & TV/Beamer) (6 Viewers)

[Marcus Venturi]

That's quite surprising. I'm interested to know if the limitation is really one window handle per application/process... or is it per input device

I will check that when I have more time.

For the moment I'm thinking for a simpler approach. The idea ist just to listen for WM_INPUT (in PreFilterMessage) and then analyse what's comming. If it's for me, then I return true, if not I return false.

As the RemotePlugins already registers the necessary input filter I don't have to. I would just call GetRawInputData and decode the data myself...

 

[mm1352000]

I will check that when I have more time.

I look forward to the result.

P.S.: My interest comes from my implementation of raw-input/HID handling for certain tuner remote controls in TVE 3.5, without awareness that there might be side-effects...
https://github.com/MediaPortal/Medi...inhan/RemoteControl/RemoteControlHid.cs#L1283

As the RemotePlugins already registers the necessary input filter I don't have to. I would just call GetRawInputData and decode the data myself...

Yes, good point. However, if the registration was done with RIDEV_INPUTSINK then I think only the registered window may receive messages. Otherwise your window must be the active/focused window in order to receive the messages.

 

[Stéphane Lenclud]

For the moment I'm thinking for a simpler approach. The idea ist just to listen for WM_INPUT (in PreFilterMessage) and then analyse what's comming. If it's for me, then I return true, if not I return false.

As the RemotePlugins already registers the necessary input filter I don't have to. I would just call GetRawInputData and decode the data myself...

You could still be able to use SharpHidLib for the parsing and handling without registering anything.
Try passing an empty RAWINPUTDEVICE array when creating your handler.
If that does not work I could modify SharpLibHid to make it work.

Ideally plug-ins should be able to register their own actions that could then be associated with a key like the rest of standard MP actions. Though that could be non trivial to implement in MP.

Alternatively we could also allow plug-ins to register to OnHidEvent but that would be specific to HID and thus rather dirty too. Should be much easier the implement than the custom action thing though. It would also only save the system from parsing multiple times each WM_INPUT. So I'm not sure that's worth the effort.

 

[Stéphane Lenclud]

P.S.: My interest comes from my implementation of raw-input/HID handling for certain tuner remote controls in TVE 3.5, without awareness that there might be side-effects...
https://github.com/MediaPortal/Medi...inhan/RemoteControl/RemoteControlHid.cs#L1283

If that's running in the TV server it should not compete with the one in MP since they are different applications right?

 

[Stéphane Lenclud]

I'm interested to know if the limitation is really one window handle per application/process... or is it per input device.

You do not register for a specific input device but rather for certain UsagePage/Usage range of events so I'm not sure how that could be a limitation here.

 

[Stéphane Lenclud]

If not needing to filter the input, maybe a possible solution would be to create another dedicated process for receiving input. Input could be passed into MP via a TCP socket or other communication technique.

Another possibility (which is a bit hacky) is to read the existing registrations before replacing them. This might enable you to manually pass the messages (using SendMessage()) to the previously registered window. One problem with this approach is that you don't ever know when the other window decides to unregister.

Both solutions should work but I would not go for any of them
First one is over the top, second one is too dirty.

 

[Stéphane Lenclud]

Yes, good point. However, if the registration was done with RIDEV_INPUTSINK then I think only the registered window may receive messages. Otherwise your window must be the active/focused window in order to receive the messages.

Not sure I understand that right. INPUTSINK means you will also get WM_INPUT messages when your application is in the background.
You can then check the event to see if you received it while in the background and based on that decide or not to do something with it.
MP is registering for background messages and configuration specifies if something should be done with them while in the background.

 

[mm1352000]

P.S.: My interest comes from my implementation of raw-input/HID handling for certain tuner remote controls in TVE 3.5, without awareness that there might be side-effects...
https://github.com/MediaPortal/Medi...inhan/RemoteControl/RemoteControlHid.cs#L1283

If that's running in the TV server it should not compete with the one in MP since they are different applications right?

Correct. My concern is: what happens when 2 TV Server plugins need to use raw input. I'm disappointed that my design is not as scalable/flexible as I thought.

 

[mm1352000]

ou do not register for a specific input device but rather for certain UsagePage/Usage range of events so I'm not sure how that could be a limitation here.

You're right. It had been too long since I looked at my code. I should have said usage-page/usage.
So I mean (example): can one window register to receive the general desktop page while another registers to receive the keyboard/kepad page? ...or what about different windows registering for different usage ranges on the same usage page?

Both solutions should work but I would not go for any of them
First one is over the top, second one is too dirty.

Ha, I don't blame you.
Note that Hauppauge remotes are already supported using the first method, so it isn't as over the top as you might think.

INPUTSINK means you will also get WM_INPUT messages when your application is in the background.

My comment was to point out that the definition of "you" and "your" appears to be limited to one window. As it says in the doc, you must provide the window handle:

If set, this enables the caller to receive the input even when the caller is not in the foreground. Note that hwndTarget must be specified.

So my understanding is that only that single registered window would receive the desired WM_INPUT messages for the given usage-page + usage range combination. In the context of this discussion, the implication is that the MP HID handler's window will be the only window that receives messages (regardless of background/focus status).

Further, the limitation to one window receiving messages still applies overall when registration is done without RIDEV_INPUTSINK. However, the actual receiving window changes depending on which window has focus. If your receiver window never has focus then I'd expect it never receives any raw input WM_INPUT messages.

 

[Marcus Venturi]

You could still be able to use SharpHidLib for the parsing and handling without registering anything.
Try passing an empty RAWINPUTDEVICE array when creating your handler.

Passing an empty RAWINPUTDEVICE leads to a System.IndexOutOfRangeException.

Meanwhile I implemented a simple solution based on the code of @nicsergio for the case that the plugin is used from MediaPortal.
If the plugin is used from the MediaPortal Configuration I use your SharpLibHid because in this case I must register the handler.

An I have noticed that my TestPatterns plugin is also affected by this problem.