Forums

There are already several threads on this topic in the german subsection. Sorry for repeating it here, but I think this problem needs a little more attention, since it exists already more than 2 months and makes many things unusable in OpenPli for Vu+ boxes.

Please include the patch that Vix-Team or VTI-team has included in their image. Pressing "7" three times should result in an "r", not in "777" as it is today.

Where does it not work and where do you need SMS input????

This is a known issue, which, in our opinion, should be fixed in the drivers.
Not worked around in our image.

Entering any string (e.g.password) in the fritzbox-plugin does not work. I searched the forum and found the issue in the german subsection. There are reports that the issue is also in TimerEdit and other text-input fields, but I did not test it myself. Will do this evening.
Also one guy wants to use the sms-style input within the station-list e.g. to jump to the stations beginning with "t" by pressing "8". He reports that this does not work either. I never used this feature, so I cannot confirm that this works in other images.

This is a known issue, which, in our opinion, should be fixed in the drivers.

Thanks for the answer. My picture as a C/C++/Linux-developer, but OpenEmbedded/Enigma2-newbie is: A driver should receive RC-events and notify the application about the key that was pressed. If I press 3 times "7" the driver should notify the application 3 times about the "7". How can a driver know that SMS-style input is wanted instead? I think this is an application task. But maybe my understanding of a "driver" is wrong here.

Not worked around in our image.

That's a pity. Came from VTI image, but want to change as I noticed that their enigma2-code is not open and they are violating GPL.
Edited by feelfree, 29 February 2012 - 10:10.

here's what happens:
handling of keyboards and remotes is different.
For remotes, you get the 'sms style input' when you press number keys in text fields.
For keyboards, of course you do not get that, as that would be rather annoying.

So how to decide which device we're dealing with?
We just check for the existence of a KEY_A in the device. If there is such a key, it's a keyboard. If there isn't, it's a remote.

So far so good, all is working fine like expected.

Along comes vu+, with input devices with invalid key maps, so remotes are presenting themselves as keyboards, and big surprise, they start behaving as keyboards, so no more 'sms input' possibility.

To add to that, VU+ promised by e-mail to fix the issue in their drivers. That was a few days after the last driver release.

Thanks for the explanation. Just compared lib/driver/rcinput.cpp of code.vuplus.com and OpenPli.
A hack for myself seems fairly easy. Will setup the toolchain this weekend a try to build my own OpenPli image with fixed input for Vu+ then.

To add to that, VU+ promised by e-mail to fix the issue in their drivers. That was a few days after the last driver release.

Ok, then I'll wait at least until the next driver release of Vu...
Edited by feelfree, 29 February 2012 - 11:32.

Along comes vu+, with input devices with invalid key maps, so remotes are presenting themselves as keyboards, and big surprise, they start behaving as keyboards, so no more 'sms input' possibility.

Have thought about this one more time. What could Vu+ do here to support their Ultimo Remote? This remote has a regular remote layout on one side and a keyboard qwertz layout at the back. It is still ONE remote with ONE driver, but it can be used as a regular remote AND as a keyboard. I guess there's no other easy fix than the way Vu already did.

It is totally correct that the driver reports that the remote has a Key "A" - it has. Ok, one could say that then you should actually USE the qwerty-keyboard at the backside of the remote (I guess this will work), but for users with OneForAll and Harmony-Remotes that's not an option.
Edited by feelfree, 29 February 2012 - 12:18.

The rc and the backside are two different devices, one is a rc, and the other is a keyboard.
So they should have been presented as two different devices, and we would not have had this problem.

It would also not be a problem if the "A" key actually worked.

Thanks for the explanations. Have patched rcinput.cpp accordingly and now have successfully worked around the first out of 3 problems i have with OpenPli so far ;-)

@feelfree: Would it be possible to upload your patched rcinput.cpp so that others (like me) could use it? The only reason why I'm currently not using OpenPLi on my Ultimo is because of this very annoying bug, and I would be more than happy to get a fix for it.

Many thanks in advance!

needs a compiled e2 binary with the patch.

Oh, too bad. But thanks for the reply.

If you want, you can download my binary (compiled in march) here.
Edited by feelfree, 20 April 2012 - 21:55.

Thanks alot! But from my understanding, this file would be overwritten each time an online-update deploys a new e2 build, right? Which is more or less daily...

I was thinking that rcinput.cpp is a standalone-file, which is obviously not the case. So I'm afraid this is not really a solution. But thanks anyway!

Why do you wan to update daily anyway? I have set up my system so that I like it and I see no reason to do any update at all.
Can you think of anything new in the e2 binary, let's say in the last 3 months or so, for that it would be worth updating (or recompiling in my case)?

what about this one: http://openpli.git.s...f7e1d91491d6b1e

@feelfree: To be honest, if I'd like to stay at a given level without updating, I could as well stay with the VTI image. The main reason for me to switch to PLi would be its fast and regular updates.

@theparasol: What does that mean? The description sound like it would be the fix for the issue, but since the issue is still present, this cannot be the case. Can you clarify that?