208 replies to this topic

[Rob van der Does]

LOL: I just got a reply back from VU+ stating that in their image and also in the images based on that, there seems to be no problem.
Now you and I know the cause of this, but I really need to have some strong arguments as to why in images with an other basis there is a (driver related) problem indeed. My statement 'it doesn't work in PLi' doesn't seem to be very impressive. The more (objective) arguments I can give them, the more chance we have in getting this fixed.

Does this mean you say that VU+ doesn't care about our request and find support of "PLi" not important point?

I don't intend to say any more then what I said. I can't look into anybody's head.......
All I want is to get as many arguments as possible to support PLi's request.

[mirakels]

LOL: I just got a reply back from VU+ stating that in their image and also in the images based on that, there seems to be no problem.
Now you and I know the cause of this, but I really need to have some strong arguments as to why in images with an other basis there is a (driver related) problem indeed. My statement 'it doesn't work in PLi' doesn't seem to be very impressive. The more (objective) arguments I can give them, the more chance we have in getting this fixed.

Satkiekerd, that seems to say it all again from Vu+.
'our image works fine so everybody else is wrong'.
It is quite clear the driver reports wrong statements about the capabilities of the remote control. from my local version of enigma2 I collect some extra debug info about the keymap capabilities and those are obviously wrong. Vu probably thinks: 'the "a" key canbe produced by pressing the "2" key twice so the remote support the "a" key.' I guess that would be the wrong way of thinking.

I also tested slow-motion again and I can't get it to work on mkv/avi files or DVDs (did not test recordings). I tested this on the solo2 using a virgin openpli and a virgin openvix image. So I'm puzzled it seems to work for you.

Another thing that would be useful is some good information about the /proc/stb files; meanings, formats, possible values etc.

[Rob van der Does]

Thanks Mirakels, that's info I can pass on.

My slow motion tests have been executed on recordings (on DUO, UNO, Ultimo and Solo2) and all work fine. I have no MKV's to test, but I will test DvD's. Thanks for that suggestion; I'll report the results here.

[Rob van der Does]

LOL: I just got a reply back from VU+ stating that in their image and also in the images based on that, there seems to be no problem.
Now you and I know the cause of this, but I really need to have some strong arguments as to why in images with an other basis there is a (driver related) problem indeed. My statement 'it doesn't work in PLi' doesn't seem to be very impressive. The more (objective) arguments I can give them, the more chance we have in getting this fixed.

Satkiekerd, that seems to say it all again from Vu+.
'our image works fine so everybody else is wrong'.

And/or it says something about the way I asked/told them. It's always difficult to interpret written conversations by third parties. That's one of the reasons I want to have as much (objective) info as possible.

Edited by SatKiekerd, 30 January 2013 - 10:38.

[Rob van der Does]

My slow motion tests have been executed on recordings (on DUO, UNO, Ultimo and Solo2) and all work fine. I have no MKV's to test, but I will test DvD's. Thanks for that suggestion; I'll report the results here.

I tested DVD slow-motion, using the same DVD on all boxes. All boxes were on the latest ViX-image; UNO also on the latest PLi-image.
The UNO, DUO, Ultimo, Solo2, Technomate-Twin, Odin M9 and the ET9200 all failed this test. The only thing they do is showing the slow-speed indicator.......
The only box that did pass the test was the ET5000!

I take it this (mal)function is driver related?

[WTE]

My slow motion tests have been executed on recordings (on DUO, UNO, Ultimo and Solo2) and all work fine. I have no MKV's to test, but I will test DvD's. Thanks for that suggestion; I'll report the results here.

I tested DVD slow-motion, using the same DVD on all boxes. All boxes were on the latest ViX-image; UNO also on the latest PLi-image.
The UNO, DUO, Ultimo, Solo2, Technomate-Twin, Odin M9 and the ET9200 all failed this test. The only thing they do is showing the slow-speed indicator.......
The only box that did pass the test was the ET5000!

I take it this (mal)function is driver related?

ET5000 and ET9200 use same drivers. So it's strange that ET9200 didn't work.

Anyway on VU+ it's not working but this is report many time as well.

[redribo]

I send email to vu for the problems of rc buttons,
no reply yet.

[mirakels]

to elaborate on the reported device key capabilities:

vusolo2 reports:

Input device "dreambox advanced remote control (native)" is a keyboard
Device: /dev/input/event0 keycaps
KEY_1  KEY_2  KEY_3  KEY_4  KEY_5  KEY_6
KEY_7  KEY_8  KEY_9  KEY_0  KEY_MINUS  KEY_EQUAL  KEY_BACKSPACE
KEY_Q  KEY_W  KEY_E  KEY_R  KEY_T  KEY_Y  KEY_U  KEY_I
KEY_O  KEY_P  KEY_ENTER  KEY_A  KEY_S
KEY_D  KEY_F  KEY_G  KEY_H  KEY_J  KEY_K  KEY_L  KEY_SEMICOLON
KEY_APOSTROPHE  KEY_GRAVE  KEY_LEFTSHIFT  KEY_BACKSLASH  KEY_Z  KEY_X  KEY_C  KEY_V
KEY_B  KEY_N  KEY_M  KEY_COMMA  KEY_DOT  KEY_SLASH
KEY_LEFTALT  KEY_SPACE
KEY_RIGHTALT  KEY_HOME  KEY_UP
KEY_PAGEUP  KEY_LEFT  KEY_RIGHT  KEY_END  KEY_DOWN  KEY_PAGEDOWN
KEY_MUTE  KEY_VOLUMEDOWN  KEY_VOLUMEUP  KEY_POWER
KEY_STOP
KEY_HELP  KEY_MENU
KEY_NEXTSONG  KEY_PLAYPAUSE  KEY_PREVIOUSSONG  KEY_RECORD
KEY_EXIT
KEY_PLAY
BTN_LEFT BTN_RIGHT
KEY_OK  KEY_INFO
KEY_SUBTITLE
KEY_TV
KEY_RADIO  KEY_TEXT
KEY_AUDIO  KEY_VIDEO  KEY_RED  KEY_GREEN
KEY_YELLOW  KEY_BLUE  KEY_CHANNELUP  KEY_CHANNELDOWN  KEY_NEXT
KEY_PREVIOUS

et9000 reports:

Input device "dreambox remote control (native)" is a remotecontrol
Device: /dev/input/event0 keycaps
KEY_1  KEY_2  KEY_3  KEY_4  KEY_5  KEY_6
KEY_7  KEY_8  KEY_9  KEY_0
KEY_KP7
KEY_KP8  KEY_KP9  KEY_KP4  KEY_KP5  KEY_KP6  KEY_KP1
KEY_KP2  KEY_KP3  KEY_KP0
KEY_UP
KEY_LEFT  KEY_RIGHT  KEY_DOWN
KEY_MUTE  KEY_VOLUMEDOWN  KEY_VOLUMEUP  KEY_POWER
KEY_STOP
KEY_HELP  KEY_MENU
KEY_PLAYPAUSE  KEY_RECORD
KEY_REWIND  KEY_EXIT
KEY_FASTFORWARD
KEY_OK  KEY_INFO
KEY_TV
KEY_RADIO  KEY_TEXT
KEY_AUDIO  KEY_VIDEO  KEY_RED  KEY_GREEN
KEY_YELLOW  KEY_BLUE  KEY_CHANNELUP  KEY_CHANNELDOWN  KEY_NEXT
KEY_PREVIOUS

Input device "dreambox advanced remote control (native)" is a remotecontrol
Device: /dev/input/event1 keycaps
KEY_1  KEY_2  KEY_3  KEY_4  KEY_5  KEY_6
KEY_7  KEY_8  KEY_9  KEY_0
KEY_UP
KEY_LEFT  KEY_RIGHT  KEY_DOWN
KEY_MUTE  KEY_VOLUMEDOWN  KEY_VOLUMEUP  KEY_POWER
KEY_STOP
KEY_HELP  KEY_MENU
KEY_FILE
KEY_BOOKMARKS
KEY_PLAYPAUSE  KEY_RECORD
KEY_REWIND  KEY_EXIT
KEY_FASTFORWARD
KEY_SEARCH
KEY_OK  KEY_INFO  KEY_TIME
KEY_PROGRAM  KEY_EPG
KEY_SUBTITLE  KEY_SCREEN
KEY_TV
KEY_RADIO  KEY_TEXT
KEY_AUDIO  KEY_VIDEO  KEY_LIST  KEY_RED  KEY_GREEN
KEY_YELLOW  KEY_BLUE  KEY_CHANNELUP  KEY_CHANNELDOWN  KEY_NEXT
KEY_RESTART  KEY_PREVIOUS

Input device "front panel" is a remotecontrol
Device: /dev/input/event2 keycaps
KEY_UP
KEY_DOWN
KEY_VOLUMEDOWN  KEY_VOLUMEUP  KEY_POWER
KEY_MENU
KEY_EXIT
KEY_OK

[Trial]

Hi,
can you tell me how to get this table and especially "is a keyboard"?

ciao

[mirakels]

the 'is a keyboard' is from the enigma log. (start enigma in telnet session)

The rest of the info is a local patch to enigma and some postprocessing script.

[Trial]

Hi,

the 'is a keyboard' is from the enigma log. (start enigma in telnet session)

thank you. I never noticed it. If I can reproduce it is a bug and must be fixed. It must also be checked in the OI. I will report it in bugtracker if I checked.

ciao

[Trial]

Hi,
this is what the OI says:

Input device "dreambox advanced remote control (native)" is not a keyboard.

ciao

[jooe]

Here is a fix for RC numeric keys with the best regards to OpenPli team.

diff -u --recursive --new-file a/rc.cpp b/rc.cpp
--- original/rc.cpp 2012-08-19 17:26:07.000000000 +0400
+++ new/rc.cpp 2013-02-02 21:59:17.000000000 +0400
@@ -148,6 +148,9 @@

bool eRCInputEventDriver::isKeyboard()
{
+ /* this ugly fix for solo2 */
+ if (strcasestr(getDeviceName().c_str(), "remote") != NULL)
+  return false;
  /* check whether the input device has KEY_A, in which case we assume it is a keyboard */
  return hasCap(keyCaps, KEY_A);
}

Attached Files

•  fix_rc_for_solo2.diff.zip   946bytes   32 downloads

Edited by jooe, 2 February 2013 - 19:15.

[redribo]

How install this?

[mirakels]

Hi,
this is what the OI says:

Input device "dreambox advanced remote control (native)" is not a keyboard.

ciao

what is "OI"?

[Pedro_Newbie]

OI = Original Image? So the image supplied by VU+?

[mirakels]

if that is the case I'm not supprised it 'works' well in OI. The enigma code in the vu image is quite different from the latest available. The vu enigma does not check the keymap capabilities so gets passed the driver reporting keyboard keys.

[mirakels]

Here is a fix for RC numeric keys with the best regards to OpenPli team.

diff -u --recursive --new-file a/rc.cpp b/rc.cpp
--- original/rc.cpp 2012-08-19 17:26:07.000000000 +0400
+++ new/rc.cpp 2013-02-02 21:59:17.000000000 +0400
@@ -148,6 +148,9 @@

bool eRCInputEventDriver::isKeyboard()
{
+ /* this ugly fix for solo2 */
+ if (strcasestr(getDeviceName().c_str(), "remote") != NULL)
+  return false;
  /* check whether the input device has KEY_A, in which case we assume it is a keyboard */
  return hasCap(keyCaps, KEY_A);
}

and we do like ugly code, do we? https://www.nluug.nl...tract/ab21.html

[littlesat]

Milo did commit something today that might fix the issue in a more ellegant way

[android]

Milo's commit seems like fixing non-working digit keys.

About keycaps,
There are 2 types of R/C available for Solo2.
Default R/C without keyboard and optional R/C with keyboard.
Driver should take care of both types of R/C.
In this case, what keycaps of solo2 driver should be?