208 replies to this topic

[Firex]

While I understand the basic concerns from Open Pli, but it is nevertheless kind of sad for an normal "enduser" that there is/comes apparently no solution for the VU+Solo2 (Tuner; HbbTV; RC) which is integrated in the OpenPli Image ...

Regards

[pieterg]

indeed, very sad

[malakudi]

OpenVIX has an "elegant" fix for the RC VU+ bug. It adds an option in the remote control configuration screen. Of course it would be best for VU+ to fix this, but the patch is nice and can be implemented similar to patches for alpha blending etc - using hardware feature variable. I could rework this patch from OpenVIX for OpenPLI, if it is going to be accepted.

Edited by malakudi, 6 March 2013 - 12:43.

[redribo]

vix-openaaf have a choice of turn on " text option"

[littlesat]

And probably thanks to them VU does not fix it.... Wonderfull isn't?

Edited by littlesat, 6 March 2013 - 13:43.

[malakudi]

@littlesat: We've talked this before. Although I understand your point of view, my belief is that if the patch is not a "dirty" patch but a well designed solution that can help users, then it should be applied. If this is not the case, then why apply fixes like the one for the alpha blending acceleration?

if test `echo "$BOXTYPE" | cut -b 1-2` == "vu"; then
	AC_DEFINE(FORCE_NO_BLENDING_ACCELERATION, 1,[define when the framebuffer acceleration does not have alphablending support, though the autodetection might indicate that it does])
	AC_DEFINE(FORCE_NO_FILL_ACCELERATION, 1,[define when the framebuffer acceleration does not have fill support])
	AC_DEFINE(FORCE_ADVANCED_REMOTE, 1,[define to fixup the input device identification when the remote control is actually an 'advanced' remote (with play/forward/rewind keys)])
fi

Why don't we remove those too then?

Always think of close sourced drivers as device "firmware". If the linux kernel demanded for all hardware to fix their inconsistences in their firmware, it would only have device support similar to Hurd.

Just my 2 cents.

Edited by malakudi, 6 March 2013 - 14:13.

[littlesat]

Vu should should deliver support... so they should fix their problem...
That time we did it indeed... but somewhere a final line must be drawn...
Now it is up to VU... So probably we could wait for ever... except when VU suddenly does deliver support...

Edited by littlesat, 6 March 2013 - 14:23.

[pieterg]

@littlesat: We've talked this before. Although I understand your point of view, my belief is that if the patch is not a "dirty" patch but a well designed solution that can help users, then it should be applied. If this is not the case, then why apply fixes like the one for the alpha blending acceleration?

if test `echo "$BOXTYPE" | cut -b 1-2` == "vu"; then
	AC_DEFINE(FORCE_NO_BLENDING_ACCELERATION, 1,[define when the framebuffer acceleration does not have alphablending support, though the autodetection might indicate that it does])
	AC_DEFINE(FORCE_NO_FILL_ACCELERATION, 1,[define when the framebuffer acceleration does not have fill support])
	AC_DEFINE(FORCE_ADVANCED_REMOTE, 1,[define to fixup the input device identification when the remote control is actually an 'advanced' remote (with play/forward/rewind keys)])
fi

Why don't we remove those too then?

Always think of close sourced drivers as device "firmware". If the linux kernel demanded for all hardware to fix their inconsistences in their firmware, it would only have device support similar to Hurd.

Just my 2 cents.

yes, those defines are as ugly, and should not be necessary.
However, there is a big difference.
I've introduced those defines after I found out that new e2 stuff I added did not work on the vu's.
So before, it was working, and after I added stuff, it would no longer work.
Therefore, I felt responsible for things being broken on vu hardware, because of my developments, and decided to work around it.

With the input device issues, it's not something we introduced or broke from our side, it's something which vu+ introduced, but has not worked properly since day 1.
So I consider it their own responsibility to make it work.

[Firex]

So probably we could wait for ever... except when VU suddenly does deliver support...

In this case, wouldn`t it be the clearest solution that Open Pli offers no Image for VU+Solo2 until support from VU+ is done?

An image which does not cover all functions - in my opinion - is not a great satisfactory neither für the Open Pli Team, nor for the users ...

Edited by Firex, 6 March 2013 - 15:10.

[littlesat]

In this case, wouldn`t it be the clearest solution that Open Pli offers no Image for VU+Solo2 until support from VU+ is done?

Proberly... But this might only work when Aaf en ViX also do stop the support... probably VU will fix their drivers then...

Currently you are stuck with an ugly DIY patch...

Edited by littlesat, 6 March 2013 - 15:14.

[malakudi]

I truly understand the point of view of the developers. It's their work and they are not willing to make VU+ any favors. It's VU+ fault, they should fix it, I aggree with that. But still, I would like to help those users that bought VU+ Solo2 to experience the superiority of OpenPLI. OpenPLI drives the advancements in enigma2.

What if I could provide a kernel module or userspace utility that goes between enigma2 and VU drivers, fixing wrong reporting about the remote? (capturing ioctl or something - it is not clear to me right now how this could be done) Would this be accepted?

edit: I have an issue with vtuners on VU+ Solo2. When restarting enigms2, sometimes USB DVB-T tuner is shown as multituner (supporting DVB-S/DVB-T/DVB-C). It usually happens if I do init 4; init 3 . Further restarting enigma2 doesn't help, you need to reboot box.

Edited by malakudi, 6 March 2013 - 15:23.

[littlesat]

Why should it help users? If VU want to sell to users they should fix their drivers.... And the remote control is not the only showstopper here...

Edited by littlesat, 6 March 2013 - 15:28.

[theparasol]

Just remove the images for the crappy VU from webpage and set a nice link, with explanation why, a sum of all buggy things that need to workaround by openpli and a email address where users can send their compliments to VU support.

[Rob van der Does]

Just remove the images for the crappy VU from webpage and set a nice link, with explanation why, a sum of all buggy things that need to workaround by openpli and a email address where users can send their compliments to VU support.

That would be my suggestion as well.
Either provide an image that works fine, or (if you can't/won't for no matter what reason) don't provide an image at all. Now you make users happy when they see a PLi-image to be available, only to disappoint them when they find out that crucial functions don't work.

[Trial]

Hi,

...The Solo2 supports the Ultimo RC and this has a keyboard.

Which doesn't work...

with support I meant also it works. I tested it.

Of course when PLi does not really support die Solo2 you cannot test it.

ciao

[jooe]

edit: I have an issue with vtuners on VU+ Solo2. When restarting enigms2, sometimes USB DVB-T tuner is shown as multituner (supporting DVB-S/DVB-T/DVB-C). It usually happens if I do init 4; init 3 . Further restarting enigma2 doesn't help, you need to reboot box.

I have exactly the same issue, using my USB DVB-T (siano chipset)

[MiLo]

Hi,

...The Solo2 supports the Ultimo RC and this has a keyboard.

Which doesn't work...

with support I meant also it works. I tested it.

Have both ultimo and solo2, the letter keys have never worked on either of them. Maybe my remote is just broken, that could also be the case.

[Trial]

Hi,
did you test the original image? The RC support of PLi and VU+ is not the best in this area.

ciao

[hemertje]

Hi,
did you test the original image? The RC support of PLi and VU+ is not the best in this area.

ciao

[WanWizard]

We are aware things work (different) in the original image.

Issue here is that the drivers, supplied by VU+, report the wrong RC type. The original image has hacked it's way around that in the Enigma2 code, which they can do, because they only have to support one brand. We have to support over 15 different brands and models, so hacking is out of the question. It will lead to code that is no longer maintainable. The vendor must fix this.

If the vendor doesn't do that, maybe OpenPLi users should not buy a VU+. A vendor has to listen to it's customers if it wants to make money.

So (as Hemertje already implies) it's not a PLi issue, it's a driver, and therefore a vendor, problem.