94 replies to this topic

[WanWizard]

Nothing was removed, the problem is the driver, it doesn't report the remote as being alphanumerically capable. Which is checked in rc.cpp.

The VU+ image probably doesn't even check, but enable it hardcoded in rc.cpp.

 

USB keyboards work fine.

[Abu Baniaz]

I tried a USB keyboard on a solo 4k, most buttons worked. Easiest method to test was network setup, so that I can confirm worked. With regards to your IR remote, is it because receiver is expecting text-like entry instead of keyboard. Do you have same problem if virtual keyboard is active?

The Solo 4K is with a friend so I can't test for you. Will a duo 4k do?

Sent from my Moto G (5S) using Forum Fiend v1.3.3.

[serdeliuk]

I tried a USB keyboard on a solo 4k, most buttons worked. Easiest method to test was network setup, so that I can confirm worked. With regards to your IR remote, is it because receiver is expecting text-like entry instead of keyboard. Do you have same problem if virtual keyboard is active?

The Solo 4K is with a friend so I can't test for you. Will a duo 4k do?

Sent from my Moto G (5S) using Forum Fiend v1.3.3.

 

Thanks, can you please try with the usb keyboard to input text in the SSID field from wifi settings, with my IR qwerty RC does not work.

[WanWizard]

The USB keyboard is a HID device, not an RC, and is therefore handled differently (i.e. not by rc.cpp). I doubt this test is in any way useful.

[serdeliuk]

Well, indeed, this test could not lead anywhere, initially I thought that the keymap is different, however, i am curious to see if a different input source could put text in that field.

[serdeliuk]

Nothing was removed, the problem is the driver, it doesn't report the remote as being alphanumerically capable. Which is checked in rc.cpp.

The VU+ image probably doesn't even check, but enable it hardcoded in rc.cpp.

 

USB keyboards work fine.

 

I had a look at rc.cpp which seems to have some strange things added.

First of all it is set a variable based on RC device name if it contains "remote control" string

 

in eRCInputEventDriver::eRCInputEventDriver following variable is set

m_remote_control = getDeviceName().find("remote control") != std::string::npos; /* assume remote control when name says so */

Then check to see if RC is keyboard or not based on above variable

bool eRCInputEventDriver::isKeyboard()
{
        if (m_remote_control)
                return false;
        /* check whether the input device has KEY_A, in which case we assume it is a keyboard */
        return hasCap(keyCaps, KEY_A);
}

To me this seems to be a BUG added at some point for an unknown reason, the above function will always return false as all STBs have that sting in device name, but some of them have IR keyboards

Edited by serdeliuk, 10 May 2020 - 20:21.

[serdeliuk]

I will create a conditional patch to avoid this situation at least for Vu+ devices on which the qwerty RC works.

Edited by serdeliuk, 10 May 2020 - 20:24.

[serdeliuk]

dcq  Sorry, my child gain access to the keyboard ) please remove this post if possible... 

Edited by serdeliuk, 10 May 2020 - 21:02.

[WanWizard]

Maybe you could ask @athoik for comments, he added it, I've seen it for the first time now, and have no clue why.

 

But it may indeed disable the alphanumeric keyboard check when it shouldn't.

[serdeliuk]

I have build a quick patch to set  the `m_remote_control` variable to false and all suddenly started to work.

 

Attached is a version of enigma2 which can be installed as an upgrade by anyone who wants qwerty support over IR in OpenPli 7.2  on Vu+ Solo4K, until you add proper support for this too

Attached Files

•  enigma2_2.7+git18419+0490c0b-r1_vusolo4k.ipk   7.59MB   0 downloads

Edited by serdeliuk, 10 May 2020 - 22:01.

[WanWizard]

It might be better to discuss this, and/or offer a pull request and have athoik respond, otherwise we'll never know

• why this was added
• and what reverting it will break

because the fact that is now works for you, doesn't mean the other 70-odd boxes aren't affected...

[athoik]

The vu+ needs a workaround.

This commit makes check in a generic way.

https://github.com/O...03f92427ffc6faa

A further improvement would be force numeric control or keyboard on runtime,
at least for remote controls having keyboard as well.

[serdeliuk]

Thanks, but who added that vu_rc_workaroud and why? if broke things why was not removed but another workaround was added?

 

As far as i know all STBs have that string in the device name, not just VU so that code does not makes sense, as long as is for the internal IR.

 

When it comes to IR the device is not the remote control per se, but the INTERNAL IR receiver which cannot be keyboard or numeric RC, the driver tells what happens with the receiving data, so it is bad to guess what kind of device is in the air based on the DRIVER name

 

That code block ALL qwerty IR keyboards, not only VU ones.

[serdeliuk]

I am not able to see the reason why the VUPLUS_RC_WORKAROUND was added, does anyone know?

 

Previously to that forever true boolean (m_remote_control) was the following, but do the same, render unusable all VU qwerty remotes, but only VU ones this time.

bool eRCInputEventDriver::isKeyboard()
{
#ifdef VUPLUS_RC_WORKAROUND
        return(false);
#else
        /* check whether the input device has KEY_A, in which case we assume it is a keyboard */
        return hasCap(keyCaps, KEY_A);
#endif
}

[WanWizard]

As I understand, I was wrong, the problem is the other way around.

 

All VU+ drivers report the remote has KEY_A, and therefore would be classified by Enigma as alphanumeric, while they are not. This is done so at least all normal remotes still work.

 

This issue has been reported to VU+ on several occasions, but I assume their drivers can''t see the difference either. And as we don't have access to the source of VU+s own image, we don't know what workaround they hacked in...

 

p.s. Enigma uses this information so it knows whether to present the user with a full keyboard, or with an SMS style numeric keyboard.

[serdeliuk]

Indeed, the event driver from VU have a lot more keys than a normal driver, for qwerty, but why to render unusable all qwerty keys instead to investigate what problem have the virtual keyboard?

 

It seems that the workaround was added to allow text input through on-screen virtual keyboard alike a phone pad, letters and numbers on the same key.

That seems the initial issue, trying to fix mosts users text input the solution was to remove qwerty support.

In the  beginning only for VU users then for all all other qwerty users.

Edited by serdeliuk, 11 May 2020 - 11:54.

[WanWizard]

You still don't seem to understand what I write.

 

All remotes that are not alphanumeric use an SMS-style virtual keyboard. Which are 99.9999% or all remotes. Until a few Enigma releases back, that was they only option.

 

Then a full virtual keyboard was added with support for alphanumeric input, and a check was added in rc.cpp to check if the remote was capable of alphanumeric input by checking for support of the letter "A".

 

This worked fine, until VU+ released their Qwerty remote. All of a sudden, the drivers reported ALL VU+ remotes were capable of alphanumeric input, either because of a bug in the drivers, or because the drivers themselfs can't see the difference and VU+ decided to make that all alpha capable. Either way, it broke the remote handling in Enigma. VU+ has appearently worked around this in their Enigma, but because they violate the GPL license and don't publish their source, we don't know.

 

Which left us with a dilemma: should we support 99.9999% of the remotes out there and hardcode all VU+ remote's to numeric-only, or should we support the odd user with a qwerty remote. Easy choice.

 

So unless you can find a why for rc.cpp to distinguish the qwerty remote from all other VU+ remotes, its a problem that can't be fixed by us.

[serdeliuk]

You still don't seem to understand what I write.

 

Why do you think i don't understand what you write? So far i was able to find the "bug" and trace back to the initial issue while you where wrong all the time and now suddenly i do not understand?

 

To me, disabling all qwerty events was the easy path into solve the input issue instead to dig into that.

Not to mention, initially those where disabled only for VU users, but then a new idea was to disable to whole qwerty users from all platforms.

[WanWizard]

Because you seem to suggest we didn't dig into this and we disabled all alpha support, and also did it on purpose.

 

We spend months trying to find a solution and persuade VU+ to fix their drivers, before eventually we added the IF VU workaround. I can't comment on Athoik's removal and more generic code, and what side effects that has.

 

What "whole qwerty users" and what "all platforms" are you talking about? What other brands have alphanumeric remotes that we don't know about, that are mishandled by this code?

[serdeliuk]

I don't know if you did dig into this or not, but the result is awful, on purpose it is because this is the result, that code didn't appear there by itself.

 

Are you kidding when ask who else have qwerty right? https://forums.openp...ndpost&p=163293

 

To me the starting with VUPLUS_RC_WORKAROUND was a wrong path to solve the issue which has nothing to do with the drivers at all, they added more keys than E2 expected, so what?