Reply to thread

Message

<blockquote data-quote="CyberSimian" data-source="post: 1169908" data-attributes="member: 141969">Thank you for confirming that the Ortek/Hama DID work correctly in earlier releases. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite24" alt="(y)" title="Thumbs Up&nbsp; &nbsp; (y)" loading="lazy" data-shortname="(y)" />[USER=140174]@Stéphane Lenclud[/USER] - The workaround that I am investigating really is just that --&nbsp; a workaround, and not the correct solution.&nbsp; Based on my experiments, I think that there must have been an unwanted side effect from the introduction of &quot;Generic HID&quot; that has caused the &quot;Centarea HID&quot; not to work correctly any more. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite3" alt=":(" title="Frown&nbsp; &nbsp; :(" loading="lazy" data-shortname=":(" />I am finding that keystrokes entered via the keyboard are thrown away (so nothing appears on the screen).&nbsp; I am using the on-screen keyboard in the &quot;Search in Titles&quot; panel.&nbsp; In order to get the keystrokes to be honoured, I have been adding explicit definitions for them in the &quot;Centarea HID.xml&quot; file.&nbsp; That does seem to work -- the keystrokes are passed through, and finally appear on the screen. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile&nbsp; &nbsp; :)" loading="lazy" data-shortname=":)" />&nbsp; But this is a regression from previous releases. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite16" alt=":cry:" title="Crying&nbsp; &nbsp; :cry:" loading="lazy" data-shortname=":cry:" />So it seems that there is some part of the keyboard/remote handler that would previously accept undefined keys from the keyboard, and simply pass them through unchanged, whereas now it passes them through only if they have definitions in the xml file.&nbsp; Does that give a clue as to where the regression may have occurred? <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite5" alt=":confused:" title="Confused&nbsp; &nbsp; :confused:" loading="lazy" data-shortname=":confused:" />-- from CyberSimian in the UK</blockquote>

[QUOTE="CyberSimian, post: 1169908, member: 141969"] Thank you for confirming that the Ortek/Hama [b]DID[/b] work correctly in earlier releases. (y) [USER=140174]@Stéphane Lenclud[/USER] - The workaround that I am investigating [i]really is[/i] just that -- a workaround, and not the correct solution. Based on my experiments, I think that there must have been an unwanted side effect from the introduction of "Generic HID" that has caused the "Centarea HID" not to work correctly any more. :( I am finding that keystrokes entered via the keyboard are thrown away (so nothing appears on the screen). I am using the on-screen keyboard in the "Search in Titles" panel. In order to get the keystrokes to be honoured, I have been adding explicit definitions for them in the "Centarea HID.xml" file. That [i]does[/i] seem to work -- the keystrokes are passed through, and finally appear on the screen. :) But this is a regression from previous releases. :cry: So it seems that there is some part of the keyboard/remote handler that would previously accept undefined keys from the keyboard, and simply pass them through unchanged, whereas now it passes them through only if they have definitions in the xml file. Does that give a clue as to where the regression may have occurred? :confused: -- from CyberSimian in the UK [/QUOTE]

Verification