Forums

Hi All,

Apologies if this is not the right place to post this, but was hoping someone could help me with a keyboard mapping issue I have on VUsolo2. I have a qwerty usb keyboard works fine on many images but with OP4.0 only basic function keys like up,down,left,right, ESC and backspace seem to work. No letters or numbers register. I am sure this is a kepmapping issue but as I am relatively unexperienced in all this, I have no idea how to go about sorting this out.

Could someone kindly advise?

Thanks

I am not 100% sure, but it's probably the following:

- vuplus "advertises" it's remote control interface (aka drivers) as being qwerty-capable keyboards

- this makes enigma think it's a genuine (external) keyboard and that's why it doesn't show the on-screen-keyboard when entering alpha keys, so you can't enter alpha keys

- to work around this, on the solo2 and duo2 we ignore the "qwerty capable" property and then alpha key input works

- but now external keyboards fail to be recognised as full qwerty capable

 

This is not easy to fix, sorry.

Erik thanks for your reply. I think I understand you but still could we not still make OP4 dual compatible so it works with a standard external USB keyboard? It's a shame because with the BH and VIX images, external USB keyboard works fine without problem. My preference is Openpli so I do hope this can be fixed in a later release.

Everything can be fixed. It's the question whether it's worth the effort vs. the yield. Also it would contaminate the enigma source even further with vuplus workarounds, I don't think the main developers would be really enthousiastic about that.

oh it's worth the effort If a developer reads this please please and please give us full usb keyboard support. Even as a plugin so it's an optional install.
thanks.

As this is something we do in our spare time, it's up to us whether we think it's worth the effort to sacrifice the spare time Especially if it's only for one brand!

@guitarman,

Did you try OE-Alliance based image? They are open source (just like OpenPLi) and they are integrate more fixes.

So if that is already applied on OE-A is "easy" to fix on OpenPLi.

No that's not the case. The OE-A images have a whole bunch of patches copied from the vuplus repo, that are actually workarounds specific for ommitments in the vuplus (and only vuplus) drivers. We feel they are too specific to vuplus to implement in a software component like enigma, which is supposed to be hardware-independent. Any hardware dependency should be abstracted by the driver layer, just like other manufacturers do.

<thinking loud>

Vu is the first one that created transcoding into drivers, right?

 

Since OpenPLi (and others) follows any groundbreaking changes (eg ioctrl in dvbmediasink by Xtrend for WMV/WMA) and baptizes those as standard, i would like to see if other will follow Vu standard in transcoding.

</thinking loud>

 

Anyway if Enigma manufactures breaking "standards" its bad.

 

But... wait, are there standards on Enigma word? NO. Only those we baptize (first implement = standard).

 

Is there any documentation what manufactures must follow? NO.

 

It there wiliness between manufactures to create some standards? NO.

 

What is i see coming, is fragmentation.. and OpenPLi officially support only Xtrend.

 

Time will show...

You're missing a tiny bit called linux dvb api... (and other linux standard api's, e.g. the event driver api), which are not adhered to by vuplus.

Ok,
 
Here is an example: AUDIO_SET_BYPASS_MODE

int ioctl(int fd, int request = AUDIO_SET_BYPASS_MODE, boolean mode);

PARAMETERS
int fd = File descriptor returned by a previous call to open().
int request = Equals AUDIO_SET_BYPASS_MODE for this command.
boolean mode = Enables or disables the decoding of the current Audio stream in the DVB subsystem.TRUE Bypass is disabled, FALSE Bypass is enabled.

Does the "standard" mention use (bypass) 0x22 for DDP?

I assume Erik is referring to the transcoding.
The current solution, with the two streamproxies, just isn't very elegant.

How about the input/event driver implementation. VU+ offers one device that reports all events, from all possible remotes. This is exactly the problem of the TS. DMM offers multiple devices, one without alpha support for the "plain" remote control and one with alpha support for the wireless keyboard. This is sensible.

 

Anyway, I would be considering making a workaround for VU+ if there were a way to differentiate between a genuine keyboard and a VU+ "quasi"-alpha-keyboard (or any other possible not-really-alpha-keyboard). But as VU+ presents it's remote control as a "real keyboard" afaik that's not possible.

No that's not the case. The OE-A images have a whole bunch of patches copied from the vuplus repo, that are actually workarounds specific for ommitments in the vuplus (and only vuplus) drivers. We feel they are too specific to vuplus to implement in a software component like enigma, which is supposed to be hardware-independent. Any hardware dependency should be abstracted by the driver layer, just like other manufacturers do.

In an ideal world you are of course completely correct. But as this is not the case, even far from it, and in the end the user wants an image that supports all the functionality of his box, one sometimes has to make compromises. And as imagebuilders hardly have any influence on the drivers supplied by the manufacturers there's only one solution: hard work to create compromises (work-arounds if you like).

The OE-a supports the build environment for images for roughly 70 different boxes for 15 different image builders. Thanks to the way the compromises have taken place all boxes are indeed fully supported, without causing any harm to other boxes.

Of course this does take a considerable amount of effort; both in developing and in maintaining the OE and the images themselves. But is worth the effort.

 

But if you know a better way to 'correct' flaws caused by manufacturers you could get a lot of admiration!

Veranderd door SatKiekerd, 20 december 2013 - 17:13

And as imagebuilders hardly have any influence on the drivers supplied by the manufacturers there's only one solution: hard work to create compromises (work-arounds if you like).

 

I do not agree... as long imagebuilders accept adapting durty work-a-rounds and compromises the manufacturers do not need to invest in making thinks properly....

 

In a world where imagebuilders do not accept adapting durty work-a-rounds and do not compromise the manufacturers could feel that by selling less devices... and they they need to invest to fix things

 

But we get again into the never ending "chicken and egg" saga...

The OE-a supports the build environment for images for roughly 70 different boxes for 15 different image builders.

You do not have to repeat it... In between we are really aware that the OE alliance does support more different images and tons of other boxes.

Its simply not going to happen. After all those years, one has to be realistic.

@ Littlesat: be my guest and dream on. Even when living in a beautiful countryside the world is not ideal and never will be.

But be aware that only users are the victims of your dream, nobody else.

 

Sometimes it's good to wake up and to change ones attitude. For the benefit of many.

Veranderd door SatKiekerd, 21 december 2013 - 05:34

Gosh! This has really kicked off as a debate..At the end of the guys my request is a simple one, that I hope would improve Input device support for Open pli. With a generic keyboard plugged in some keyboard functions already work, up,down,left,right,enter,back space..is it not just the case to map letters A to Z , 0 to 9 in code?. It's a pain to log into my NAS with a remote and I don't want to spend £50 on a IR keyboard from DM. Thanks

To really fix this vu must change to allow multiple input stuff.... Just like most other tenders do.

At the end of the guys my request is a simple one, 

If only it were, it would already be fixed...