Map on-screen colour buttons to keyboard Function keys

stevebow · Post by **stevebow** » Wed Mar 15, 2017 12:27

A Feature Request. As far as I am aware, when using a keyboard there are no keyboard key equivalents of the on-screen colour buttons. This would be useful e.g. when renaming a long list of titles with an external keyboard, where the Rename function is mapped to a long press of the Red button by default.

A working solution is to add the following code to the "<map context="ColorActions">" element in /usr/share/enigma2/keymap.xml

Code: Select all

		<key id="KEY_F9" mapto="red" flags="b"/>
		<key id="KEY_F9" mapto="redlong" flags="l"/>
		<key id="KEY_F10" mapto="green" flags="b"/>
		<key id="KEY_F10" mapto="greenlong" flags="l"/>
		<key id="KEY_F11" mapto="yellow" flags="b"/>
		<key id="KEY_F11" mapto="yellowlong" flags="l"/>
		<key id="KEY_F12" mapto="blue" flags="b"/>
		<key id="KEY_F12" mapto="bluelong" flags="l"/>

This will map the Red, Green, Yellow and Blue on-screen buttons to F9, F10, F11, F12 respectively.

This does not appear to break anything as the remote's colour keys still function as expected.

Thanks,
Steve

prl · Post by **prl** » Wed Mar 15, 2017 12:50

I think it's a good idea, but general solution needs to go a bit further than just that addition.

ColorActions isn't by a long way the only context that maps the coloured buttons to action names. Coloured buttons (not always all of them) are also mapped to actions in these contexts:
SetupActions
InfobarInstantRecord
InfobarExtensions
SatlistShortcutAction
InfobarActions
InfobarSubserviceSelectionActions
InfobarRedButtonActions
InfobarSeekActions
MediaPlayerSeekActions
TeletextActions
ChannelSelectBaseActions
EPGSelectActions
EventViewActions
EventViewEPGActions
MsgBoxActions
ShortcutActions
SleepTimerEditorActions
MediaPlayerActions
CCcamInfoActions
MediaPlayerActions
CCcamInfoActions
ButtonSetupActions

The choice of which function buttons to use also needs some thought, because F11 & F12 require the use of the Fn shift key on the wireless keyboard that Beyonwiz sells, F5 is already used in the InfobarMenuActions context and in the ShortcutActions context, F1-F4 are already defined as the coloured buttons (which I hadn't noticed before).

Some thought might also need to be given to how coloured button and function button definitions are used in Screens/ButtonSetup.py.

Mappings for other commonly-used remote buttons onto keyboard buttons might also be useful.

MrQuade · Post by **MrQuade** » Wed Mar 15, 2017 12:52

I don't think there is anything controversial in that suggestion.

I'll pop it straight into the issue tracker.

Enhancement #578 added.

I included a note to add the colour keys to any other contexts that it is required in. The F9-F12 keys are not used elsewhere, so adding them will not remove any existing functionality.

MrQuade · Post by **MrQuade** » Wed Mar 15, 2017 13:11

prl wrote: F1-F4 are already defined as the coloured buttons (which I hadn't noticed before).

Hmm, having another look at where KEY_F1 is defined. The F1-F4 do not appear to currently do anything obviously useful. Perhaps it is just better to use F1-F4 rtaher than F9-F12 given the default Beyonwiz KB limitations.

As long as they always map to do whatever the colour buttons do, then things should be fairly simple to define?

prl wrote:Mappings for other commonly-used remote buttons onto keyboard buttons might also be useful.

Good idea, though do we have a way of documenting these shortcut keys?

We could start by looking at what the keyboard mappings are set to in a software package such as Kodi, and look to those as a reference.

IanSav · Post by **IanSav** » Wed Mar 15, 2017 16:35

Hi,

In my rework of Setup.py I have already hit the issue of mapping remote control and keyboard buttons.

For my example to Stevebow I used F9 - F12 as they were clearly not used in the keymap file so could safely be used without conflict. I have also been testing using or creating mappings for other buttons:

Remote -> Keyboard
EXIT -> ESCAPE
OK -> ENTER
PREV -> HOME
NEXT -> END
INFO -> INSERT
BACK -> BACKSPACE
CH + -> PAGE UP
CH - -> PAGE DOWN
VOL + -> VOL +
VOL - -> VOL -
MUTE -> MUTE
PLAY/PAUSE -> PLAY/PAUSE
RED -> F9 (To be F1 if there are no conflicts.)
GREEN -> F10 (To be F2 if there are no conflicts.)
YELLOW -> F11 (To be F3 if there are no conflicts.)
BLUE -> F12 (To be F4 if there are no conflicts.)
MEDIA -> TAB
MENU -> F5
FAV -> F6
EPG -? F7
HELP -> F8
REW -> , or [
FF -> . or ]
STOP -> =

I haven't wanted other buttons yet so I haven't thought about reallocating them.

I wouldn't mind seeing a readable version the key layout of the Beyonwiz keyboard. I would like to ensure the mappings I end up using will work just as well on this keyboard as it does on my Microsoft keyboard.

Regards,
Ian.

MrQuade · Post by **MrQuade** » Wed Mar 15, 2017 17:14

IanSav wrote: I wouldn't mind seeing a readable version the key layout of the Beyonwiz keyboard. I would like to ensure the mappings I end up using will work just as well on this keyboard as it does on my Microsoft keyboard.

It looks like one of these to me.

prl · Post by **prl** » Wed Mar 15, 2017 17:53

That certainly looks like what I have, apart from the screenprint on the touchpad.

As I mentioned before, there's already a precedent for the use of F1-F4 as the coloured buttons in the ShortcutActions context.

I'd prefer not to have F9-F12 used because, as I mentioned earlier, on the Beyonwiz-supplied wireless keyboard, F11 is only accessible as Fn-F9 and F12 as Fn-F10. Having a simple left-to-right sequence of function buttons in the same RGYB order as on the remote would be preferable.

Other contexts that use function buttons are:
InfobarMenuActions: F5
FunctionKeyActions: F1, F2, F3
ButtonSetupActions: F1, F2, F3, F4

Paul_oz53 · Post by **Paul_oz53** » Wed Mar 15, 2017 19:23

MrQuade wrote: It looks like one of these to me.

The one I have is exactly like that one - no surprise since Jai sent it!

Definitely prefer avoiding F11-F12 because they are hard to operate, as prl has pointed out.

Fully support expanding the list for all major keys because of the functionality it will provide. I will use the kb a lot more if we make this work well.

To a major degree the allocations are arbitrary.
Let's just agree a set and lock it in. IanSav's list looks good to me - do others agree?

Star6key · Post by **Star6key** » Thu Mar 16, 2017 10:21

Paul_oz53 wrote: Let's just agree a set and lock it in. IanSav's list looks good to me - do others agree?

Seems fine to me. Individual changes can always be made in the Keymap script.

MrQuade · Post by **MrQuade** » Thu Mar 16, 2017 10:45

I'd suggest some additional mappings for the playback controls as well, for those keyboards that lack media buttons.
Also, I can't tell from the keymap file, but "i" appears to be used as info in many, but not all places. Hard for me to tell as I am not sure exactly which screens use which contexts.

IanSav · Post by **IanSav** » Thu Mar 16, 2017 11:45

Hi MrQuade,

MrQuade wrote:Hard for me to tell as I am not sure exactly which screens use which contexts.

This is a very significant issue. Too much code uses action maps that have little or no relationship to the current context. Making a change to an action in one context has unexpected and unwanted impacts elsewhere.

Regards,
Ian.

prl · Post by **prl** » Thu Mar 16, 2017 12:24

IanSav wrote:...
MrQuade wrote:Hard for me to tell as I am not sure exactly which screens use which contexts.
This is a very significant issue. Too much code uses action maps that have little or no relationship to the current context. Making a change to an action in one context has unexpected and unwanted impacts elsewhere.
...

Definitely agreed.

prl · Post by **prl** » Sat Apr 14, 2018 17:26

I've been scanning through the outstanding issues and on reconsideration this looks reasonably easy to implement, though there are potential unexpected side-effects.

I think that the mapping F1, F2, F3, F4 for RED, GREEN, YELLOW, BLUE makes the most sense, especially since this context already exists:

Code: Select all

	<map context="ShortcutActions">
		<key id="KEY_F1" mapto="red" flags="mr"/>
		<key id="KEY_F2" mapto="yellow" flags="mr"/>
		<key id="KEY_F3" mapto="green" flags="mr"/>
		<key id="KEY_F4" mapto="blue" flags="mr"/>

		<key id="KEY_RED" mapto="red" flags="mr"/>
		<key id="KEY_YELLOW" mapto="yellow" flags="mr"/>
		<key id="KEY_GREEN" mapto="green" flags="mr"/>
		<key id="KEY_BLUE" mapto="blue" flags="mr"/>
	</map>

That context is used in the screens WebcamViewer, BackupRestore, SoftwareManager, WirelessLan, HarddiskSetup, InfoBarGenerics, NetworkSetup, PowerTimerEdit, TaskList and TimerEdit.

However, I don't think that the ordering makes much sense. I think it should be F1->RED, F2->GREEN, F3->YELLOW, F4->BLUE.

Extending the ColorActions context to allow the use of the same function buttons to be used instead of the colour buttons seems logical.

ShortcutActions and ColorActions differ in that the first allows for button repeats, and the second allows for long/short presses.

Other contexts where existing colour button presses might be paralleled by function buttons are:
SetupActions, InfobarInstantRecord, InfobarExtensions, SatlistShortcutAction (unused in Beyonwiz firmware), InfobarSubserviceSelectionActions (unused in Beyonwiz firmware), InfobarRedButtonActions, InfobarSeekActions, MediaPlayerSeekActions, TeletextActions, ChannelSelectBaseActions, EPGSelectActions, EventViewActions, EventViewEPGActions, MsgBoxActions.

Existing contexts that use function buttons are:
InfobarMenuActions, but it only uses F5, so there's no potential conflict there.
FunctionKeyActions uses F1-F3, but it isn't used in the Beyonwiz firmware or in enigma2-plugins (but other plugins are also used/available).

So it appears unlikely that using F1-F4 as alternative colour buttons in all contexts that use the coloured buttons is unlikely to cause problems.

The only other source of problems I can think of is that if plugins define their own contexts with coloured buttons, they most likely won't allow the use of the function buttons as alternatives for the coloured buttons. That can be fixed for plugins in the Beyonwiz repository that have their own keymap.xml files, like CutListEditor.

If anyone's interested in trying it out, I'm happy to make a patch for you to try.

IanSav · Post by **IanSav** » Sat Apr 14, 2018 18:14

Hi Prl,

Thank you for this timely post.

I had created a detailed post explaining my interest in the post and my reservations about the proposal but the forum system rejected my text and deleted the post!

In short I have just submitted a change to Setup.py (Pull Request #441 - It is my link to the pull request that is forcing the post to break!!!). This change will lead to a change in ConfigList.py. To make the ConfigList.py changes I have created a new keymap called "ConfigListActions" to replace "SetupActions" which has been commandeered by all sorts of code with potentially little to do with Setup.py based screens.

In my new keymap I intend to provide many more keyboard mappings to support users who may use a full keyboard as well as a remote control to operate their Beyonwiz. I had noted the keymap reservation of F1 through F3 and I also note that many users associate F1 with HELP. With this in mind I have currently defined F9 through F12 to represent the RED, GREEN, YELLOW and BLUE buttons respectively.

If it is considered that my concerns over using F1 through F4 are not significant then I would be more than happy to update my keymap accordingly.

Regards,
Ian.

IanSav · Post by **IanSav** » Sat Apr 14, 2018 18:36

Hi,

I just re-read my post above and compared it to my current keymap which has, in part:

Code: Select all

<!-- Keyboard buttons -->
<key id="KEY_ESC" mapto="cancel" flags="b" />
<key id="KEY_ESC" mapto="close" flags="l" />
<key id="KEY_ENTER" mapto="ok" flags="m" />
<key id="KEY_TAB" mapto="listMenu" flags="m" />
<key id="KEY_HOME" mapto="first" flags="m" />
<key id="KEY_END" mapto="last" flags="m" />
<key id="KEY_PAGEUP" mapto="pageUp" flags="m" />
<key id="KEY_PAGEDOWN" mapto="pageDown" flags="m" />
<key id="KEY_BACKSPACE" mapto="backspace" flags="mr" />
<key id="KEY_INSERT" mapto="toggleInsert" flags="m" />
<key id="KEY_DELETE" mapto="delete" flags="mr" />
<key id="KEY_LEFTBRACE" mapto="top" flags="m" />
<key id="KEY_RIGHTBRACE" mapto="bottom" flags="m" />
<key id="KEY_F5" mapto="listMenu" flags="m" />
<key id="KEY_F8" mapto="displayHelp" flags="b" />
<key id="KEY_F9" mapto="red" flags="b" />
<key id="KEY_F9" mapto="redlong" flags="l" />
<key id="KEY_F10" mapto="green" flags="b" />
<key id="KEY_F10" mapto="greenlong" flags="l" />
<key id="KEY_F11" mapto="yellow" flags="b" />
<key id="KEY_F11" mapto="yellowlong" flags="l" />
<key id="KEY_F12" mapto="blue" flags="b" />
<key id="KEY_F12" mapto="bluelong" flags="l" />

Regards,
Ian.

IanSav · Post by **IanSav** » Sat Apr 14, 2018 18:42

Hi,

I just want to try and post my pull request link to see if this is the problem: {url=https://bitbucket.org/beyonwiz/easy-ui- ... s/441}Pull Request #441{/url}.

Pull Request #441 - https://bitbucket.org/beyonwiz/easy-ui- ... quests/441

If I use the correct "[" and "]" characters instead of "{" and "}" in the link above the post becomes unacceptable! This appears to be a new forum bug.

Regards,
Ian.

prl · Post by **prl** » Sat Apr 14, 2018 19:05

IanSav wrote: ↑
Sat Apr 14, 2018 18:42
...
If I use the correct "[" and "]" characters instead of "{" and "}" in the link above the post becomes unacceptable! This appears to be a new forum bug.
...

It's probably Sucuri's strange and unpredictable anti-code injection checks at work.

One way round this is to find the offending bit of text (the hard bit) and disrupt the check like this:

Code: Select all

evilStuffSucuriDoesn'tLike

->

Code: Select all

evilStuff[color=#000000]S[/color]ucuriDoesn'tLike

A bit of experimentation generally allows you to get around the problem. The down side is that it doesn't work in [code][/code] blocks

prl · Post by **prl** » Sat Apr 14, 2018 19:10

IanSav wrote: ↑
Sat Apr 14, 2018 18:36

<key id="KEY_F11" mapto="yellow" flags="b" />
<key id="KEY_F11" mapto="yellowlong" flags="l" />
<key id="KEY_F12" mapto="blue" flags="b" />
<key id="KEY_F12" mapto="bluelong" flags="l" />[/code]

Those assignments are unfriendly to the Xtreamer keyboard that Beyonwiz sells, which requires Fn-F9 for F11 and Fn-F10 for F12. I mentioned that in the first round of discussion.

That, along with the fact that ShortcutActions uses F1-F4 for the coloured buttons already, is why I prefer F1-F4 for the coloured buttons.

IanSav · Post by **IanSav** » Sat Apr 14, 2018 19:32

Hi Prl,

I tried to get a good look at the keyboard on the Beyonwiz website but all the images are too small and lack detail. I found this image on the Internet. How does it compare to the Beyonwiz model?

: Mini wireless keyboard...

Regards,
Ian.

Star6key · Post by **Star6key** » Sat Apr 14, 2018 19:44

Hey, I've got one of those, except mines called 'iPazzPort'. It's the exact same body and key layout.

IanSav · Post by **IanSav** » Sat Apr 14, 2018 19:50

Hi Star6key,

The Rii and iPazzPort devices look identical.

I don't own either, nor a Beyonwiz keyboard, which is why I need conformation of the button tops to try and find a button combination that works on the Beyonwiz as well as other keyboards.

Regards,
Ian.

prl · Post by **prl** » Sat Apr 14, 2018 20:12

IanSav wrote: ↑
Sat Apr 14, 2018 19:32
I tried to get a good look at the keyboard on the Beyonwiz website but all the images are too small and lack detail. I found this image on the Internet. How does it compare to the Beyonwiz model?
...

I'll check in detail tomorrow, but the function button layout is certainly the same.

Paul_oz53 · Post by **Paul_oz53** » Sat Apr 14, 2018 21:15

I also have a Beyonwiz Rii mini keyboard. The idea of mapping to the function keys to colours has instant appeal.

The only limit I have is to avoid F11 and F12 as these keys are not practicable on the mini keyboard, as prl has noted.

And the colour sequence should be RED GREEN YELLOW BLUE, as suggested.

IanSav · Post by **IanSav** » Sat Apr 14, 2018 21:29

Hi,

Okay, given the layout and limitations of the Beyonwiz keyboard my proposed changes to ConfigList.py and the keymap.xml files now look like:

Code: Select all

<map context="ConfigListActions">
	<key id="KEY_RED" mapto="cancel" flags="m" />
	<key id="KEY_GREEN" mapto="save" flags="m" />
	<key id="KEY_TV" mapto="close" flags="m" />
	<key id="KEY_EXIT" mapto="cancel" flags="b" />
	<key id="KEY_EXIT" mapto="close" flags="l" />
	<key id="KEY_OK" mapto="ok" flags="m" />
	<key id="KEY_MENU" mapto="listMenu" flags="m" />
	<key id="KEY_FILE" mapto="listMenu" flags="m" />
	<key id="KEY_MEDIA" mapto="listMenu" flags="m" />
	<key id="KEY_VIDEO" mapto="listMenu" flags="m" />
	<key id="KEY_REWIND" mapto="top" flags="mr" />
	<key id="KEY_CHANNELUP" mapto="pageUp" flags="mr" />
	<key id="KEY_UP" mapto="up" flags="mr" />
	<key id="KEY_PREVIOUS" mapto="first" flags="m" />
	<key id="KEY_LEFT" mapto="left" flags="mr" />
	<key id="KEY_RIGHT" mapto="right" flags="mr" />
	<key id="KEY_NEXT" mapto="last" flags="m" />
	<key id="KEY_DOWN" mapto="down" flags="mr" />
	<key id="KEY_CHANNELDOWN" mapto="pageDown" flags="mr" />
	<key id="KEY_FASTFORWARD" mapto="bottom" flags="mr" />
	<key id="KEY_INFO" mapto="toggleOverwrite" flags="m" />
	<key id="KEY_LAST" mapto="backspace" flags="mr" />
	<key id="KEY_1" mapto="1" flags="m" />
	<key id="KEY_2" mapto="2" flags="m" />
	<key id="KEY_3" mapto="3" flags="m" />
	<key id="KEY_4" mapto="4" flags="m" />
	<key id="KEY_5" mapto="5" flags="m" />
	<key id="KEY_6" mapto="6" flags="m" />
	<key id="KEY_7" mapto="7" flags="m" />
	<key id="KEY_8" mapto="8" flags="m" />
	<key id="KEY_9" mapto="9" flags="m" />
	<key id="KEY_0" mapto="0" flags="m" />
	<!-- Keyboard buttons -->
	<key id="KEY_ESC" mapto="cancel" flags="b" />
	<key id="KEY_ESC" mapto="close" flags="l" />
	<key id="KEY_ENTER" mapto="ok" flags="m" />
	<key id="KEY_TAB" mapto="listMenu" flags="m" />
	<key id="KEY_BACKSPACE" mapto="backspace" flags="mr" />
	<key id="KEY_INSERT" mapto="toggleInsert" flags="m" />
	<key id="KEY_DELETE" mapto="delete" flags="mr" />
	<key id="KEY_HOME" mapto="top" flags="m" />
	<key id="KEY_END" mapto="bottom" flags="m" />
	<key id="KEY_PAGEUP" mapto="pageUp" flags="m" />
	<key id="KEY_PAGEDOWN" mapto="pageDown" flags="m" />
	<key id="KEY_F1" mapto="red" flags="b" />
	<key id="KEY_F1" mapto="redlong" flags="l" />
	<key id="KEY_F2" mapto="green" flags="b" />
	<key id="KEY_F2" mapto="greenlong" flags="l" />
	<key id="KEY_F3" mapto="yellow" flags="b" />
	<key id="KEY_F3" mapto="yellowlong" flags="l" />
	<key id="KEY_F4" mapto="blue" flags="b" />
	<key id="KEY_F4" mapto="bluelong" flags="l" />
	<key id="KEY_F5" mapto="listMenu" flags="m" />
	<key id="KEY_F8" mapto="displayHelp" flags="b" />
	<key id="KEY_F9" mapto="first" flags="m" />
	<key id="KEY_F10" mapto="last" flags="m" />
</map>

Thoughts?

Regards,
Ian.

prl · Post by **prl** » Sun Apr 15, 2018 13:03

IanSav wrote: ↑
Sat Apr 14, 2018 19:32
...
I tried to get a good look at the keyboard on the Beyonwiz website but all the images are too small and lack detail. I found this image on the Internet. How does it compare to the Beyonwiz model?
...

It looks identical.

Here's a slightly higher-resolution image of a different branding, but with the same layout. It's not face-on, but it's still quite readable.

prl · Post by **prl** » Sun Apr 15, 2018 13:41

Button codes sent by the non-printing buttons:

Left and right of mousepad:

Code: Select all

KEY_CONFIG		KEY_SEARCH ('WWW',)
KEY_MAIL		KEY_FILE
KEY_MUTE ('MUTE',)	KEY_HOMEPAGE
unrecognised		unrecognised (mouse buttons)

The mouse buttons on the left of the keyboard are also unrecognised.

Cluster to the top left:

Code: Select all

					KEY_VOLUMEDOWN ('VOL-',)
KEY_PREVIOUSSONG  ('REWIND', 'kbd')	KEY_PLAYPAUSE ('PLAYPAUSE',)	KEY_NEXTSONG ('FASTFORWARD', 'kbd')
					KEY_VOLUMEDOWN ('VOL-',)

Cluster to the top right:

Code: Select all

			KEY_UP ('UP',)
KEY_LEFT ('LEFT',)	KEY_ENTER ('ENTER', 'kbd')	KEY_RIGHT ('RIGHT',)
			KEY_DOWN ('DOWN',)

Left and right edges of the key area:

Code: Select all

KEY_ESC (Esc)
KEY_TAB (Tab)				KEY_PAGEUP (pgUp)
KEY_CAPSLOCK (Caps)			KEY_PAGEDOWN (pgDown)
KEY_LEFTSHIFT (Shift)

Across the bottom:

Code: Select all

KEY_PC (Fn)	KEY_LEFTCTRL (Ctrl)	KEY_LEFTALT (Alt)	KEY_RIGHTALT (AltGr	KEY_LEFTMETA (Win)

A mixed-case label, as in KEY_ESC (Esc) is for the screenprint text on the key. An uppercase label with optional flags like KEY_PREVIOUSSONG ('REWIND', 'kbd') shows that the key has an entry in Tools.KeyBindings.keyDescriptions.

IanSav · Post by **IanSav** » Sun Apr 15, 2018 15:18

Hi Prl,

Thanks for the comprehensive information, very much appreciated. I will add a few more options to the keymap proposal to embrace more of the available options.

I just need to tidy up my machine after a long day of debugging Outlook 2016 bugs with Microsoft so that I can get back to make the changes to my code. I will provide the updated keymap when I am done.

Regards,
Ian.

IanSav · Post by **IanSav** » Sun Apr 15, 2018 17:23

Hi Prl,

With the right edge KEY_PAGEUP and KEY_PAGEDOWN buttons, are they rocker buttons that also generate the KEY_HOME and KEY_END functions? If not, is it easy to generate the HOME and END functions?

Regards,
Ian.

IanSav · Post by **IanSav** » Sun Apr 15, 2018 17:43

Hi Prl,

I have just run some tests on the new kepmap proposals that I was going to post here for you to test. Unfortunately I have hit an unexpected snag.

On my standard Microsoft 101 key style keyboard I don't get KEY_F1 or KEY_F2 when I press the F1 and F2 buttons respectively. I am getting KEY_ASCII for both. The F3 and higher buttons are all working as expected.

Regards,
Ian.

prl · Post by **prl** » Sun Apr 15, 2018 19:14

IanSav wrote: ↑
Sun Apr 15, 2018 17:23
...
With the right edge KEY_PAGEUP and KEY_PAGEDOWN buttons, are they rocker buttons that also generate the KEY_HOME and KEY_END functions? If not, is it easy to generate the HOME and END functions?
...

They're not rocker buttons, but Fn-PgUp generates (make, KEY_PC), (make, KEY_HOME), (break, KEY_HOME) and Fn-PgDn generates (make, KEY_PC), (make, KEY_END), (break, KEY_END). Somehow the (make, KEY_PC) doesn't cause an UnhandledKey popup. Since it "does the right thing", I haven't looked into why.

prl · Post by **prl** » Sun Apr 15, 2018 19:15

IanSav wrote: ↑
Sun Apr 15, 2018 17:43
...
On my standard Microsoft 101 key style keyboard I don't get KEY_F1 or KEY_F2 when I press the F1 and F2 buttons respectively. I am getting KEY_ASCII for both. The F3 and higher buttons are all working as expected.
...

That's a bit weird. What ASCII character are they sending?

IanSav · Post by **IanSav** » Sun Apr 15, 2018 19:58

Hi Prl,

prl wrote: ↑
Sun Apr 15, 2018 19:15

IanSav wrote: ↑
Sun Apr 15, 2018 17:43
...
On my standard Microsoft 101 key style keyboard I don't get KEY_F1 or KEY_F2 when I press the F1 and F2 buttons respectively. I am getting KEY_ASCII for both. The F3 and higher buttons are all working as expected.
...
That's a bit weird. What ASCII character are they sending?

Pressing F1 then F2 then F3 in Live TV:

{22184}<333774.763> KEY: 59 make KEY_F1 None
{22184}<333774.928> KEY: 59 break KEY_F1 None
{22184}<333774.965> [SCREENNAME] UnhandledKey
{22184}<333775.824> KEY: 60 make KEY_F2 None
{22184}<333775.983> KEY: 60 break KEY_F2 None
{22184}<333776.023> [SCREENNAME] UnhandledKey
{22184}<333777.482> KEY: 61 make KEY_F3 None
{22184}<333777.659> KEY: 61 break KEY_F3 None
{22184}<333777.699> [SCREENNAME] UnhandledKey

Yet pressing F1 then F2 then F3 in Setup:

{22184}<333847.961> KEY: 510 make KEY_ASCII None
{22184}<333849.675> KEY: 510 make KEY_ASCII None
{22184}<333850.856> KEY: 61 make KEY_F3 None
{22184}<333851.073> KEY: 61 break KEY_F3 None
{22184}<333851.075> [ActionMap] Keymap 'ConfigListActions' -> Unknown action 'yellow'! (Typo in keymap?)
{22184}<333851.076> [SCREENNAME] UnhandledKey

It appears that something is manipulating the keycode but I haven't yet found what is doing the deed.

I have attached a current copy of the new ConfigList.py and keymap.xml if you would like to try this out yourself. The functions available, with CAPS entries for the remote control and () entries for the keyboard, are:

RED (F1) -> Cancel changes and exit
GREEN (F2) -> Save settings and exit
YELLOW (F3) -> Available for sub class Setup screens
BLUE (F4) -> Available for sub class Setup screens
REW (|<<) -> Jump to the first item in the menu list
UP (^) -> Move up one item in the menu list
PREV (HOME) -> Jump to the first option in the option list
LEFT (<) -> Move to the previous option in the option list
OK (ENTER) -> Pop up a menu list for ConfigSelection, Toggle option for ConfigBoolean
RIGHT (>) -> Move to the next option in the option list
NEXT (END) -> Jump to the last option in the option list
DOWN -> Move down one item in the menu list
FF (>>|) -> Jump to the last item in the menu list
EXIT (ESC) - > Cancel changes and exit
Long EXIT (Long ESC) -> Cancel changes and exit all menus (recursive close)
TV -> Cancel changes and exit all menus (recursive close)
MENU (TAB) -> Display a selection list as a pop up menu of all options in the current selection list
MEDIA (TAB) -> Display a selection list as a pop up menu of all options in the current selection list
INFO (INSERT) -> Toggle insert / overwrite mode for text entry
BACK (BACKSPACE) -> Delete the character to the left of cursor in ConfigText items
(DELETE) -> Delete the character under the cursor in ConfigText items
1 - 0 (A-Z, a-z, 1 - 0, etc) -> Number or SMS style data entry / characters from a keyboard

I would welcome feedback and/or thoughts on this proposed change to the Setup UI.

Regards,
Ian.

prl · Post by **prl** » Mon Apr 16, 2018 15:21

IanSav wrote: ↑
Sun Apr 15, 2018 19:58
Hi Prl,
prl wrote: ↑
Sun Apr 15, 2018 19:15

IanSav wrote: ↑
Sun Apr 15, 2018 17:43
...
On my standard Microsoft 101 key style keyboard I don't get KEY_F1 or KEY_F2 when I press the F1 and F2 buttons respectively. I am getting KEY_ASCII for both. The F3 and higher buttons are all working as expected.
...
That's a bit weird. What ASCII character are they sending?
Pressing F1 then F2 then F3 in Live TV:

{22184}<333774.763> KEY: 59 make KEY_F1 None
{22184}<333774.928> KEY: 59 break KEY_F1 None
{22184}<333774.965> [SCREENNAME] UnhandledKey
{22184}<333775.824> KEY: 60 make KEY_F2 None
{22184}<333775.983> KEY: 60 break KEY_F2 None
{22184}<333776.023> [SCREENNAME] UnhandledKey
{22184}<333777.482> KEY: 61 make KEY_F3 None
{22184}<333777.659> KEY: 61 break KEY_F3 None
{22184}<333777.699> [SCREENNAME] UnhandledKey

Yet pressing F1 then F2 then F3 in Setup:

{22184}<333847.961> KEY: 510 make KEY_ASCII None
{22184}<333849.675> KEY: 510 make KEY_ASCII None
{22184}<333850.856> KEY: 61 make KEY_F3 None
{22184}<333851.073> KEY: 61 break KEY_F3 None
{22184}<333851.075> [ActionMap] Keymap 'ConfigListActions' -> Unknown action 'yellow'! (Typo in keymap?)
{22184}<333851.076> [SCREENNAME] UnhandledKey
...

I can replicate that on the Beyonwiz-sourced Xtreamer wireless keyboard and an Apple A1048 109-key USB keyboard. It's not keyboard-specific.

It happens when the keyboard mode is set to eRCInput::kmAscii. That happens when eRCInput.getInstance().setKeyboardMode(rcinput.kmAscii) is called, or equivalently, if Screen.setKeyboardModeAscii() is called.

The first is called whenever Components.ConfigList is execing, which is the reason that it occurs in setup screens. It's also called in MovieSelection, ChannelSelection and PacketManager (PLUGIN>Software management>Advanced options>Package management).

Screen.setKeyboardModeAscii() is called from InputBox, FileCommander.InputBoxmod and VirtualKeyBoard.

The underlying bug is in lib/driver/rcinput.cpp:

Code: Select all

void eRCDeviceInputDev::handleCode(long rccode)
{
	struct input_event *ev = (struct input_event *)rccode;
	...
	if (km == eRCInput::kmAscii)
	{
		bool ignore = false;
		bool ascii = (ev->code > 0 && ev->code < 61);

But:

Code: Select all

#define KEY_F1			59
#define KEY_F2			60
#define KEY_F3			61

There is some code following that that resets the ascii flag for some keycodes in the range 0..60, but it doesn't do that for KEY_F1 or KEY_F2.

I think the test should simply be changed to ev->code < 59

prl · Post by **prl** » Mon Apr 16, 2018 16:13

Bug #639: Keyboard codes F1 & F2 sometimes handled as ASCII keys

I have tested the fix of changing the test to ev->code < 59, and it works correctly.

I'll wait for any comments on that before submitting the fix.

IanSav · Post by **IanSav** » Mon Apr 16, 2018 16:34

Hi Prl,

Thank you for finding the problem. I have been looking at the problem but didn't find the reason as yet. I will stop looking!

Fixing this should sort out the F1 and F2 issue that will make my code changes ready to commit.

If you have the time I would welcome your testing of my modified code to see if the changes work for you on your Beyonwiz keyboard. If you have any feedback I would welcome it.

Regards,
Ian.

Star6key · Post by **Star6key** » Mon Apr 16, 2018 16:42

prl wrote: ↑
Mon Apr 16, 2018 16:13
Bug #639: Keyboard codes F1 & F2 sometimes handled as ASCII keys

I have tested the fix of changing the test to ev->code < 59, and it works correctly.

I'll wait for any comments on that before submitting the fix.

No need to wait. It seems like an obvious error.

On a lighter note... I've just noticed the forum posts are an hour out. Checked my profile and apparently, I've moved to Antartica.

I keep forgetting this forum board doesn't handle DST.

Paul_oz53 · Post by **Paul_oz53** » Mon Apr 16, 2018 17:37

Star6key wrote: ↑
Mon Apr 16, 2018 16:42
...
No need to wait. It seems like an obvious error.

+1

On a lighter note... I've just noticed the forum posts are an hour out. Checked my profile and apparently, I've moved to Antartica. I keep forgetting this forum board doesn't handle DST.

I've often noticed posts aren't correctly time stamped - even in AEDST, I'm not confident the stamps are right! Maybe it's based on Vanuatu or Fiji or some other exotic location

prl · Post by **prl** » Wed Apr 18, 2018 11:08

prl wrote: ↑
Mon Apr 16, 2018 16:13
Bug #639: Keyboard codes F1 & F2 sometimes handled as ASCII keys
...

Fixed in firmware 20180417.

IanSav · Post by **IanSav** » Wed Apr 18, 2018 11:28

Hi Prl,

prl wrote: ↑
Wed Apr 18, 2018 11:08

prl wrote: ↑
Mon Apr 16, 2018 16:13
Bug #639: Keyboard codes F1 & F2 sometimes handled as ASCII keys
...
Fixed in firmware 20180417.

And confirmed working in my new ConfigList.py code.

Thank you for sorting this out.

Regards,
Ian.

prl · Post by **prl** » Wed Apr 18, 2018 11:40

No problem. Now that that's sorted, I'll give your ConfigList.py and keymap.xml changes a go.

IanSav · Post by **IanSav** » Wed Apr 18, 2018 16:52

Hi Prl,

prl wrote: ↑
Wed Apr 18, 2018 11:40
No problem. Now that that's sorted, I'll give your ConfigList.py and keymap.xml changes a go.

I will post the new and improved version shortly.

Regards,
Ian.

prl · Post by **prl** » Wed Apr 18, 2018 17:23

OK, I'll wait for that. Today, I've been fixing the EPG search problems that Paul_oz53 posted about, anyway.

prl · Post by **prl** » Wed Apr 18, 2018 18:38

I've just been browsing the code diffs for the ConfigList.py that you posted without having actually run anything.

It looks good and has some useful added functionality (and Help info).

Does the OpenPli HelpableActionMap support a description optional parameter? That's something I added in the Beyonwiz code. It's not in the OpenViX HelpableActionMap code.

I'm not sure why KEY_OK is mapped to KEY_TOGGLEOW for ConfigClock. I can't find anywhere where KEY_TOGGLEOW acts on ConfigClock (or any of its superclasses). I think the other remappings of OK for ConfigBoolean toggle and ConfigSelection menu are good.

The ActionMap in ConfigList overrides (? though it's the same priority, -2) the effect of MENU in the Setup ActionMap: in ConfigList, its action is "Display a selection list as a pop up menu of all options in the current selection list", but in Setup its action is "Cancel any changed settings and exit all menus".

peteru · Post by **peteru** » Wed Apr 18, 2018 19:46

prl wrote: ↑
Wed Apr 18, 2018 18:38
effect of MENU in the Setup ActionMap: in ConfigList, its action is "Display a selection list as a pop up menu of all options in the current selection list"

Good user interface.

prl wrote: ↑
Wed Apr 18, 2018 18:38
but in Setup its action is "Cancel any changed settings and exit all menus".

Bad user interface.

prl · Post by **prl** » Wed Apr 18, 2018 20:27

peteru wrote: ↑
Wed Apr 18, 2018 19:46
...
prl wrote: ↑
Wed Apr 18, 2018 18:38
but in Setup its action is "Cancel any changed settings and exit all menus".
Bad user interface.

Good or bad, that's its current action.

My point was more about the conflict (and with equal priority, the uncertainty about which would be acted on).

peteru · Post by **peteru** » Wed Apr 18, 2018 20:34

My point was that if there are changes to be made, then the "selection list" behaviour is clearly the preferred option, over the "discard my changes and kick me out of where I am" option.

I wonder if it would be a good idea to check for the same key being bound at the same priority level and issue a warning. It may uncover all sorts of bugs. I suspect that the weird issue we used to have with up/down keys ceasing to work would have been covered by such a check.

prl · Post by **prl** » Wed Apr 18, 2018 20:49

peteru wrote: ↑
Wed Apr 18, 2018 20:34
I wonder if it would be a good idea to check for the same key being bound at the same priority level and issue a warning. It may uncover all sorts of bugs.

That sounds like a good idea.

IanSav · Post by **IanSav** » Wed Apr 18, 2018 22:34

Hi Prl and PeterU,

The MENU being close recursive is the OpenPLi / OpenViX way of doing things. I thought it an appalling UI choice. I am converting all occurrences I refactor to Long EXIT (with a short press alternative of TV).

Since submitting the Setup.py code to PeterU for inclusion into the Beyonwiz image I believe I have proved to myself that I can take the ActionMap out of Setup.py and keep it in ConfigList.py. This will clean up the MENU / EXIT / Long EXIT / TV anomaly. It also keeps all the related code in the single source code module. I was waiting for PeterU to merge the first version and then I was going to submit updates when I submit the ConfigList.py changes.

I am trying to bring uniformity to OpenPLi, OpenViX and Beyonwiz. This is proving to be far more difficult than I could ever have imagined. OpenPLi and OpenViX have quite different motivations. They most definitely DON't see eye to eye!

I am currently negotiating with Littlesat to get a lot of changes into OpenPLi. The changes are currently being reworked to Littlesat's specification. I am also creating alternative versions of the same code to suite OpenViX and Beyonwiz. I will offer the image specific versions to both OpenViX and Beyonwiz to save them having to fix the upstream merges from OpenPLi. I did have versions of the code that were identical for all images but OpenPLi STRONGLY objected to having any OpenViX or Beyonwiz elements in "their" code. The new code will be close but will, unfortunately, still have code differences for merges but I hope the differences won;t be a pain for Huevos or PeterU to manage.

I have submitted the Beyonwiz version of ActionMap.py to both OpenPLi and OpenViX. OpenPLi immediately rejected the submission because I changed:

Code: Select all

def __init__(self, contexts = [ ], actions = { }, prio=0):

to

Code: Select all

def __init__(self, contexts=None, actions=None, prio=0):
	if not contexts:
		contexts = []
	if not actions:
		actions = {}

and then OpenViX followed suit. OpenPLi *strongly* believe that their version is more optimal and cleaner and don't particularly care that the code may be syntactically correct but is logically incorrect.

In Setup.py I also fell foul for removing the forced crash if a title is not found for a key entry.

Code: Select all

def getSetupTitle(id):
	xmldata = setupdom.getroot()
	for x in xmldata.findall("setup"):
		if x.get("key") == id:
			return x.get("title", "").encode("UTF-8")
	raise SetupError("unknown setup id '%s'!" % repr(id))

The situation only deserves an error message and an entry in the log but OpenViX *STRONGLY* want the crash and convinced OpenViX to keep it as well.

As I indicated, I am trying to navigate the mine field as best I can.

As for the ConfigClock interaction, I coded that over a year ago and must admit to having forgotten the purpose of that code. I think it was to address an issue that I later resolved in changes to my keymap plan. It was meant to toggle the AM/PM clock but I don't think it is needed with the newer code. I will check it out and adjust the code accordingly.

Regards,
Ian.

prl · Post by **prl** » Wed Apr 18, 2018 23:04

IanSav wrote: ↑
Wed Apr 18, 2018 22:34
...
In Setup.py I also fell foul for removing the forced crash if a title is not found for a key entry.
Code: Select all
def getSetupTitle(id):
	xmldata = setupdom.getroot()
	for x in xmldata.findall("setup"):
		if x.get("key") == id:
			return x.get("title", "").encode("UTF-8")
	raise SetupError("unknown setup id '%s'!" % repr(id))
The situation only deserves an error message and an entry in the log but OpenViX *STRONGLY* want the crash and convinced OpenViX to keep it as well.
...

I'm not sure I disagree all that strongly with the OpenPLi on that. I probably wouldn't do it that way, but I'd be OK with it (if, as I assume, it will crash the UI first time, every time, if the XML file doesn't have all the required fields set).

There have been a couple bugs that I've found that would have been found much earlier if their asserts had been active.

I agree with peteru that the OpenPLi folk are just plain wrong about the initialisation code in ActionMap.

About the Forum

Join us