[solved] MP1-4585 Generic HID input device support for MCE buttons (1 Viewer)

mm1352000

Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,578
    8,227
    Home Country
    New Zealand New Zealand
    I'm assuming everyone is happy with those changes and will put them on master later today or tomorrow.
    I think that would be an incorrect assumption. Please don't do that. Changes aren't merged to master until they've been tested and confirmed to work.
     

    Stéphane Lenclud

    Retired Team Member
  • Premium Supporter
  • April 29, 2013
    2,576
    1,294
    Home Country
    Germany Germany
    Thanks for the feedback @mm1352000

    I think that would be an incorrect assumption.
    Well silence means consent.

    Please don't do that.
    On your knees :D

    Changes aren't merged to master until they've been tested and confirmed to work.
    Tested and confirmed here.

    Of course I won't go ahead with those changes until the community is happy with it.
    However those test builds have been available for 2 weeks and I didn't hear of anyone who actually tried any of them.
     

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,578
    8,227
    Home Country
    New Zealand New Zealand
    Well silence means consent.
    Heh, depends who you ask. :D
    Silence over Christmas and New Year can also mean "too busy focussed on family and friends to keep up with what is going on with MP"... and a variety of other things.

    On your knees :D
    praying-man-15722388.jpg



    Tested and confirmed here.
    Unfortunately local testing doesn't usually cover every scenario/configuration in such a large community. At least that has been my experience.

    Of course I won't go ahead with those changes until the community is happy with it.
    However those test builds have been available for 2 weeks and I didn't hear of anyone who actually tried any of them.
    2 weeks is a short time in the life of MP. For most of us it is only 4 days (two weekends) at most... and when you consider that it has been Christmas and New Year...
    I'd encourage you to get the wiki docs sorted (if you haven't already), as all changes to user interfaces require documentation to be updated before merging (though in practice it doesn't always happen in that order ;) ).
    Also, if you really want to get people to try your work then the best way would be to let as many people as possible know about it. Only a certain set of people will see this thread. You could write a short blog for the home page, or a comment on social media.... or something... and that may attract other people that wouldn't otherwise be aware of what is going on here.

    In response to the discussion in the internal thread...
    I'm finding the generic HID changes a bit confusing. Currently people use generic HID for more than just media keys on the keyboard. To be clear: does the "media" handler (old generic HID code) now ignore non-media keys?
    (I ask this because I wonder whether people can continue to use it as "fallback" in case the new HID handler doesn't work for them.)

    For people that currently use MCE + generic HID to get all buttons on their remote to work: is there a chance that after upgrade, button presses would be doubled/repeated due to the new HID handler also supporting MCE? (...given that HID [new] and MCE [current] would be enabled for such people after upgrade)

    Finally, do you have a plan/timeframe for removing the future-obsolete (MCE, and any others) handlers?

    P.S.: while writing this post I happened to notice that the entry point for GetRawInputData() in Win32API.cs is incorrect. Looks like that function isn't used (there's another definition that is used instead), but might pay to fix it (or remove it).
     

    Stéphane Lenclud

    Retired Team Member
  • Premium Supporter
  • April 29, 2013
    2,576
    1,294
    Home Country
    Germany Germany
    I'd encourage you to get the wiki docs sorted
    I still need to work on that, just didn't want to start too early so as not to have to update the docs too often.

    You could write a short blog for the home page, or a comment on social media.... or something... and that may attract other people that wouldn't otherwise be aware of what is going on here.
    I didn't know I could do things like that. I certainly don't know how.

    I'm finding the generic HID changes a bit confusing.
    Now we' talking :)

    Currently people use generic HID for more than just media keys on the keyboard. To be clear: does the "media" handler (old generic HID code) now ignore non-media keys?
    (I ask this because I wonder whether people can continue to use it as "fallback" in case the new HID handler doesn't work for them.)

    Unless I missed something the former 'General HID' is just handling WM_APPCOMMAND. It has been left mostly unchanged, people who relied on that implementation before can still do so. However it has been renamed to 'Media' as it seems to be the most user friendly way to describe it. It is often refered too in such a way by hardware manufacturer which are selling Media Keyboards for instance. Though it does a little more than just Media the core of its functionality is about Media control and selection. I also needed to distinguish this implementation from the new generic HID which is actually HID this time.

    For people that currently use MCE + generic HID to get all buttons on their remote to work: is there a chance that after upgrade, button presses would be doubled/repeated due to the new HID handler also supporting MCE? (...given that HID [new] and MCE [current] would be enabled for such people after upgrade)

    I'm not sure why one would do that but it should work in exactly the same way as before if they use 'Microsoft MCE' and 'Media'.
    However I vaguely remember seeing some WM_APPCOMMAND handling in the MCE implementation so I'm really unsure how those two behave when used together.
    Earlier version of my new implementation did replace the WM_APPCOMMAND by the WM_INPUT stuff. Now that works just fine when using an actually HID device however testing this against an iMON system in MCE compatibility mode I quickly realized that iMON fabricated WM_APPCOMMAND messages bypassing the HID stack. Since quite a few other hackish software out there could be doing the same I had to put back the WM_APPCOMMAND handling as 'Media' to keep everyone happy.

    Finally, do you have a plan/timeframe for removing the future-obsolete (MCE, and any others) handlers?
    I think it will very much depend on the adoption rate and user satisfaction concerning the new implementation. I don't have anything against the legacy implementations and we may as well keep on using them indefinitely or until there is a strong case for removing some of them. Having said that and unless I missed something the 'Microsoft MCE' implementation should not be needed anymore once the generic HID has matured. The generic HID implementation should provide access to the full set of functionality offered by eHome devices.

    We could also consolidate our input system and use a proper modular plugin framework for it but that's another topic altogether.

    P.S.: while writing this post I happened to notice that the entry point for GetRawInputData() in Win32API.cs is incorrect. Looks like that function isn't used (there's another definition that is used instead), but might pay to fix it (or remove it).
    I'll take a look but I'm not aiming at cleaning our whole code base with that one change. Though I did try to straighten it up a bit :)

    Thanks for the feedback mate, it's much appreciated.
     

    edterbak

    Portal Pro
    March 4, 2008
    2,114
    1,176
    Home Country
    Netherlands Netherlands
    finally. And the results from the Netherlands.... 10 points!!! :cool:

    Disabled MCE and enabled Generic HID device in config.
    went through a lot of the actions. navigate, ok, hold up/down/left/right . info, RGBY buttons, stop play pause dvr etc.. Couldnt find a regression.

    So now I have this working, how do I switch to iMON IR receiver setup to test the same? Enable it in iMon manager and pull usb cable from MCE IR receiver and I can test? I never use the iMON thing so you need to give me some info on that :)
     

    Stéphane Lenclud

    Retired Team Member
  • Premium Supporter
  • April 29, 2013
    2,576
    1,294
    Home Country
    Germany Germany
    So now I have this working, how do I switch to iMON IR receiver setup to test the same? Enable it in iMon manager and pull usb cable from MCE IR receiver and I can test? I never use the iMON thing so you need to give me some info on that :)

    If I were you I would not bother testing iMON especially if you are not usually using it since you would not have anything to compare it with.
    Besides iMON hardware using iMON manager would not work with HID, you can use 'Media' formally known as 'General HID' which was not actual HID.
    Still following? ;) iMON Manager is just sending keyboard events and app commands.

    In theory if you are not using iMON Manager and providing that iMON hardware is actually HID you could come up with a configuration that would work with our new Generic HID. However that exercise is rather pointless and clearly outside the scope of this thread.

    Disabled MCE and enabled Generic HID device in config.
    went through a lot of the actions. navigate, ok, hold up/down/left/right . info, RGBY buttons, stop play pause dvr etc.. Couldnt find a regression.

    Thanks a lot for your time, I'm glad it works for you. Do you have the exact reference of your IR hardware, out of curiosity?
    Can you also check that 'Microsoft MCE' implementation is also free of regressions?
     

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,578
    8,227
    Home Country
    New Zealand New Zealand
    I didn't know I could do things like that. I certainly don't know how.
    Anybody is welcome to write a blog etc. If you need help with posting the text etc. then just ask. :)

    I'm not sure why one would do that but it should work in exactly the same way as before if they use 'Microsoft MCE' and 'Media'.
    Sorry, I think you may have missed my point. I'll try again... :)
    My point is that somebody who is using MCE + old generic HID now will have MCE + new HID enabled after upgrade. It isn't that people would necessarily apply that configuration intentionally. Rather, it will be the natural consequence of a standard upgrade for people who currently use that [potentially common] configuration. That's why I asked what would happen for them. Suddenly having many/all button presses repeated would not be good.

    However I vaguely remember seeing some WM_APPCOMMAND handling in the MCE implementation so I'm really unsure how those two behave when used together.
    Like I said, people use them together because sometimes MCE alone isn't enough to get all the buttons on their remote working. This may be a sign that the MCE implementation is incomplete, or that certain "MCE" remotes are not actually MCE-compliant. I don't know. I'm simply trying to look out for the interests of people that currently use MCE + generic HID.

    I think it will very much depend on the adoption rate and user satisfaction concerning the new implementation. I don't have anything against the legacy implementations and we may as well keep on using them indefinitely or until there is a strong case for removing some of them. Having said that and unless I missed something the 'Microsoft MCE' implementation should not be needed anymore once the generic HID has matured. The generic HID implementation should provide access to the full set of functionality offered by eHome devices.
    If the legacy implementations are not required then I'm strongly in favour of removing them as fast as possible. Less configuration => less setup time, less confusion => better. :)

    I'll take a look but I'm not aiming at cleaning our whole code base with that one change. Though I did try to straighten it up a bit :)
    I only mentioned it because you seem to have added that function definition. ;)
     

    edterbak

    Portal Pro
    March 4, 2008
    2,114
    1,176
    Home Country
    Netherlands Netherlands
    Thanks a lot for your time, I'm glad it works for you. Do you have the exact reference of your IR hardware, out of curiosity?
    Sure.
    Microsoft MCE remote + IR RC6 receiver
    Model 1040
    $(KGrHqZHJBQFDs8-(ENdBQ-drJ87Rg~~60_57.JPG


    $T2eC16NHJGYE9nooh,K6BQ-drSFJng~~60_57.JPG


    remote_receiver.jpg


    This should help :)
    Or do you want to know more about iMON hardware?

    If I were you I would not bother testing iMON especially if you are not usually using it since you would not have anything to compare it with.
    Besides iMON hardware using iMON manager would not work with HID, you can use 'Media' formally known as 'General HID' which was not actual HID.
    Still following? iMON Manager is just sending keyboard events and app commands.
    Ok, yeah. iMON is simulating keyboard keypresses. Knew that, so no HID.. :)

    Can you also check that 'Microsoft MCE' implementation is also free of regressions?
    I did that to begin with. No regression.
    Left Microsoft MCE ticked by default. See screenshot below.
    This worked fine. no regression.
    Naamloos2.png
    Than I tested Generic HID device. See image blow. Unticked windows MCE ofcourse.
    THis worked fine as well. No regression found so far.
    Naamloos.png
     

    CyberSimian

    Test Group
  • Team MediaPortal
  • June 10, 2013
    2,998
    1,862
    Southampton
    Home Country
    United Kingdom United Kingdom
    I'm assuming everyone is happy with those changes and will put them on master later today or tomorrow.
    Does your new HID support fix the problem with the EPG scrolling that we discussed in this thread:

    https://forum.team-mediaportal.com/threads/tv-guide-screen-bug-and-usability.126779/

    Several months ago I spent some time using the "MCE Mapping" dialogue to assign different functions to the remote-control buttons to see if I could find a function that avoided the problem, but they all exhibited the same bug. I suspect that internally the different function names actually resolve to the same numeric function code. :(

    I also have the Ortek remote control, which sends genuine WMC keyboard shortcuts instead of MCE RC6 protocol. I was really disappointed to find that when I used the MP configuration file for this remote (created by another MP user), the Ortek remote exhibited the same bug! :eek:

    And yet, using a keyboard directly does not exhibit this bug. I also set up an AutoHotKey script to map the Ortek WMC keyboard shortcuts to MP keyboard shortcuts, and that does not exhibit the bug either.

    After all of this experimenting I came to the conclusion that there is some fundamental bug in MP's remote-control processing software, and that any remote that uses that software will exhibit this bug. Only if that software is bypassed completely (e.g. by using keyboard input) can the bug be avoided.

    Currently my HTPC runs MP 1.9.0 pre, which I think means that I cannot test your new HID support (and I do not have a spare partition at the moment to create a test system). Sorry about that. :(

    -- from CyberSimian in the UK
     

    Users who are viewing this thread


    Write your reply...
    Top Bottom