home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
Support
Input / Output interfaces
Mini Display
Zalman HD135 VFD (VlSys Mplay)
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="cybrmage" data-source="post: 220050" data-attributes="member: 51680"><p>FINALLY!!!!! PROGRESS!!!!!</p><p></p><p></p><p></p><p>That's not exactly accurate... Yes, the remote doesn't function.... But the state machine does... And the "guess" I made on how to handle the remote's "repeat" function appears to be valid... (The last set of logs you provided confirm it). </p><p></p><p>What happens is that the received data is scrubbed of invalid data (IE: data that can not be a temperature reading, or a remote button) and then it is processed. If the state machine receives a remote button press, it caches it... and waits for the 0x7E command (This appears to be a button press indicator...)... When the 0x7E indicator is received, it fires the event that is associated with the button. (but the last version tried to fire the 0x7E and not the cached button)</p><p></p><p>If a 0x7E is received AND there is no button in the cache AND at least 100ms has passed since the last event was fired, we fire the last button we received.</p><p></p><p></p><p></p><p></p><p>Good... finally 8-}</p><p></p><p>I also notice, in the last logs you posted, that the 0xA0 command has a 2 second delay after being sent, and the 0x00 0x00 0x00 sequence has a 500ms delay....</p><p></p><p>So that probably means that the 0xA0 is a "reset" command and the 0x00 sequence is probably an "attention" command.</p><p></p><p>I have added the appropriate delays to the new version.</p><p></p><p></p><p></p><p>That would be because MediaPortal does not wait for those drives to remount... MediaPortal start right where it left off, and expects all the device to be ready when it is... I beleive that this is already a known issue...</p><p></p><p></p><p></p><p>This sequence is always sent immediately before the 0xA4 0x76 command, so I suspect that you are correct.</p><p></p><p></p><p></p><p></p><p>MHC must REALLY want the display to go to standby mode.... it sends it to the display a lot!!!</p><p></p><p></p><p>Actually... the logs show that the 0x0B byte can also be 0x6F... It appears in your logs (although 0x0B is much more frequent) and the code provided by -Manfred-... I changed it to 0x0B because I assumed that it way an aberant occurence...</p><p></p><p></p><p></p><p>I've used it in the past as well... I'm still searching for an alternative for you 8-}</p><p></p><p></p><p></p><p>If you'll excuse me.... I'm going to go crawl under a rock.... 8-}</p><p></p><p></p><p></p><p></p><p>I especially like people who open a new thread asking for a better solution, because they don't like the current solution... when they did not participate in the development of the current solution....</p><p>Or, those who demand that a certain feature be added because their specific OEM hardware supports it....</p><p>Or, those who demand that the latest experimental source code gets added to the SVN...</p><p>or,.... Oh... Sorry... I'm ranting again... oops 8-}</p><p></p><p>I have a simple solution when things like that happen... I ignore them. I stop developing, and I take the code that I have written and I apply it to projects that I will actually use... Their loss.... I don't use MediaPortal for my HTPC... I use SageTV.... I develop code for MediaPortal because I like that challenges that come with driver development... If it's not appreciated, I'll move on to developing something else for something else.</p><p></p><p>Fortunately... The work on this driver seems to be appreciated... 8-}</p><p></p><p></p><p></p><p></p><p>Sure... No problem...</p><p></p><p></p><p>Regards,</p><p>CybrMage</p></blockquote><p></p>
[QUOTE="cybrmage, post: 220050, member: 51680"] FINALLY!!!!! PROGRESS!!!!! That's not exactly accurate... Yes, the remote doesn't function.... But the state machine does... And the "guess" I made on how to handle the remote's "repeat" function appears to be valid... (The last set of logs you provided confirm it). What happens is that the received data is scrubbed of invalid data (IE: data that can not be a temperature reading, or a remote button) and then it is processed. If the state machine receives a remote button press, it caches it... and waits for the 0x7E command (This appears to be a button press indicator...)... When the 0x7E indicator is received, it fires the event that is associated with the button. (but the last version tried to fire the 0x7E and not the cached button) If a 0x7E is received AND there is no button in the cache AND at least 100ms has passed since the last event was fired, we fire the last button we received. Good... finally 8-} I also notice, in the last logs you posted, that the 0xA0 command has a 2 second delay after being sent, and the 0x00 0x00 0x00 sequence has a 500ms delay.... So that probably means that the 0xA0 is a "reset" command and the 0x00 sequence is probably an "attention" command. I have added the appropriate delays to the new version. That would be because MediaPortal does not wait for those drives to remount... MediaPortal start right where it left off, and expects all the device to be ready when it is... I beleive that this is already a known issue... This sequence is always sent immediately before the 0xA4 0x76 command, so I suspect that you are correct. MHC must REALLY want the display to go to standby mode.... it sends it to the display a lot!!! Actually... the logs show that the 0x0B byte can also be 0x6F... It appears in your logs (although 0x0B is much more frequent) and the code provided by -Manfred-... I changed it to 0x0B because I assumed that it way an aberant occurence... I've used it in the past as well... I'm still searching for an alternative for you 8-} If you'll excuse me.... I'm going to go crawl under a rock.... 8-} I especially like people who open a new thread asking for a better solution, because they don't like the current solution... when they did not participate in the development of the current solution.... Or, those who demand that a certain feature be added because their specific OEM hardware supports it.... Or, those who demand that the latest experimental source code gets added to the SVN... or,.... Oh... Sorry... I'm ranting again... oops 8-} I have a simple solution when things like that happen... I ignore them. I stop developing, and I take the code that I have written and I apply it to projects that I will actually use... Their loss.... I don't use MediaPortal for my HTPC... I use SageTV.... I develop code for MediaPortal because I like that challenges that come with driver development... If it's not appreciated, I'll move on to developing something else for something else. Fortunately... The work on this driver seems to be appreciated... 8-} Sure... No problem... Regards, CybrMage [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Support
Input / Output interfaces
Mini Display
Zalman HD135 VFD (VlSys Mplay)
Contact us
RSS
Top
Bottom