644 replies to this topic

[Rob van der Does]

IMHO a BSP is neither closed source nor comparable with drivers nor required.

See (almost) all image builders who do their job without such a layer.

 

A BSP is only for the easy of hobby-imagebuilders; using a BSP they have no work to do at all to support hardware, and they can blame the manufacturer for everything that is not working 100%.

[malakudi]

You are a bit unfair. BSP is for the ease of hobby-imagebuilders? OpenPLi is hobby-imagebuilders? BSP was implemented to put some pressure on the box manufacturers. They can't have everything easy for them. Especially since in OpenPLi is happening the biggest development of the open-source enigma2. Sure, OpenATV and oe-alliance are trying to support every box without any help from the manufacturers, but what else have they brought to Enigma2? And why supporting crappy boxes with multiple bugs in drivers (by adding workarounds on enigma2 code) is a good thing?

IMHO, BSP is a great concept in order to make the box manufacturers to actually be responsible for the software quality of the drivers of their boxes. And it is great concept to give awareness to customers buying the box about which companies actually do some work and which do not.

Edited by malakudi, 21 November 2015 - 10:11.

[Erik Slagter]

Indeed, it's a bit of give-and-take.

[Rob van der Does]

@ Malakudi: I agree with what you say. But that doesn't contradict my wording in any way.

 

As a personal note, and for what it's worth:

1- I absolutely don't agree with ATV's attitude to support every single box that's on the market. That seems to be their only concern, not the quality of the firmware.
2- PLi is indeed the only E2-developper. All other images (try to) do is making images more user friendly. But that goes without any E2-development (although some development in other area's is good, as well as fixing bugs in E2).

3- An image is more then E2; E2 is just the (only) application that is embedded in the firmware.

[MiLo]

A BSP is only for the easy of hobby-imagebuilders; using a BSP they have no work to do at all to support hardware, and they can blame the manufacturer for everything that is not working 100%.

 

Quite correct. The manufacturer chose to build a closed-source infrastructure and must therefore bear the consequences. The BSP clearly marks the boundaries between what manufacturers are responsible for, and what the team will do.

 

If any manufacturer provides open source drivers and hardware, my offer of creating and maintaining Linux support (in other words: The BSP) for free still stands.

[WanWizard]

Indeed, the BSP is a separation of responsibilities, and provides abstraction which makes it easier to develop the upper layers.

 

Or I should say "should make", because unfortunately it is also the case that not everything that should be in the BSP, i.e. everything that is manufacturer and/or hardware related, is in the BSP. Which is mainly because of the refusal of the others to work with a BSP. Instead, they incorporate all sort of hacks in their code (check OpenWebif for example) to work around differences between different hardware models. So we can't fully utilize it without having to fork a lot of community code.

 

Any developer worth her/his salt would be horrified with these kind of dependencies in the code. We had these discussions with the others, but they seem to prefer good old-fashioned hacking instead of clean and professional code.

 

And to be clear, OpenPLi hasn't invented the BSP. BSP stands for "Board Support Package", and is used in any development project where abstraction from underlying hardware is needed.

[Neo64]

Well said, Teacher, I'm in because of his explanation and never wanted to give pressure to downplay your work, which most have always usdo percentage in my life testings with multiple receivers using your images
Aki is site and time to give thanks, and I should get, got

Edited by Neo64, 21 November 2015 - 18:42.

[Neo64]

some new suggestion sense 4K ???????

[WTE]

You are a bit unfair. BSP is for the ease of hobby-imagebuilders? OpenPLi is hobby-imagebuilders? BSP was implemented to put some pressure on the box manufacturers. They can't have everything easy for them. Especially since in OpenPLi is happening the biggest development of the open-source enigma2. Sure, OpenATV and oe-alliance are trying to support every box without any help from the manufacturers, but what else have they brought to Enigma2? And why supporting crappy boxes with multiple bugs in drivers (by adding workarounds on enigma2 code) is a good thing?

IMHO, BSP is a great concept in order to make the box manufacturers to actually be responsible for the software quality of the drivers of their boxes. And it is great concept to give awareness to customers buying the box about which companies actually do some work and which do not.

 

You see that images makers still add workarounds inside e2 for the "crappy" boxes.
I get even more and more build error because some BSP layers are not setup right.

 

A good BSP layer should only have drivers and kernel parts.

I see not why this must be done through an external git BSP layer

[WanWizard]

 

A good BSP layer should only have drivers and kernel parts.

I see not why this must be done through an external git BSP layer

 

That is not correct.

 

The BSP layer should contain everything that is required to make full abstraction from the underlying hardware. That includes kernel parts and drivers, but should also include hardware capability definitions, remote control information and images, an image of the hardware itself, etc. It should also contain all other hardware/vendor related stuff, like closed source blindscan or hbbtv solutions.

 

Unfortunately, the other image builders don't see it this way, and seem to prefer to litter the code of both Enigma and plugins with runtime detections, which are difficult to maintain (since most manufacturers can't be bothered to provide correct information, every box out there seems to report it's a DM8000), and require constant attention and modification every time a new model is released.

 

Since this is (or should be) generic, the BSP must be in a separate repository so everyone can use the same BSP, and focus their attention and energy on developing the higher layers. Also, if it is a separate BSP, it is simple to have it maintained by someone that has no rights for the repositories of these higher layers. In particular the developer from the manufacturer, the one person that is a position to update the BSP.

 

And if a manufacturer is serious about his product, he will have no problem with this. If on the other hand the manufacturer (or distributor) is going for the quick buck and only wants to hop on the OpenPLi train to boost sales, it will become immediately clear to customers that this manufacturer lacks in support, and people should not purchase its hardware.

[WTE]

 

 

A good BSP layer should only have drivers and kernel parts.

I see not why this must be done through an external git BSP layer

 

That is not correct.

 

The BSP layer should contain everything that is required to make full abstraction from the underlying hardware. That includes kernel parts and drivers, but should also include hardware capability definitions, remote control information and images, an image of the hardware itself, etc. It should also contain all other hardware/vendor related stuff, like closed source blindscan or hbbtv solutions.

 

Unfortunately, the other image builders don't see it this way, and seem to prefer to litter the code of both Enigma and plugins with runtime detections, which are difficult to maintain (since most manufacturers can't be bothered to provide correct information, every box out there seems to report it's a DM8000), and require constant attention and modification every time a new model is released.

 

Since this is (or should be) generic, the BSP must be in a separate repository so everyone can use the same BSP, and focus their attention and energy on developing the higher layers. Also, if it is a separate BSP, it is simple to have it maintained by someone that has no rights for the repositories of these higher layers. In particular the developer from the manufacturer, the one person that is a position to update the BSP.

 

And if a manufacturer is serious about his product, he will have no problem with this. If on the other hand the manufacturer (or distributor) is going for the quick buck and only wants to hop on the OpenPLi train to boost sales, it will become immediately clear to customers that this manufacturer lacks in support, and people should not purchase its hardware.

 

 

I agree that all box relates stuff should be done in the BSP layer or like most other images do with a separate layer.

 

 

I hope that this option will be available for OpenPli images. It will make it lot easier for images makers and manufactures when no e2 adjustments must been made.

[WanWizard]

We can't do that, because that requires cooperation from all other image makers. If we go by ourselfs, most of the plugins will no longer work on OpenPLi.

 

And unfortunately, as I said other image makers can't be bothered, they simply refuse to cooperate, and seem to prefer to hack their way around everything, instead of solving it structurally. For example, the BSP should define a machine feature HAS_TRANSCODING, so all the code has to do is to check if this feature is enabled. And not check if it's an ET10000, a VU Duo2, a Mutant HD2400, and a handful of others. Because this means code changes every time a new box comes to market.

 

With the correct BSP, that new box would compile and be operational with all required features directly.

[pop_eye]

We can't do that, because that requires cooperation from all other image makers. If we go by ourselfs, most of the plugins will no longer work on OpenPLi.

 

And unfortunately, as I said other image makers can't be bothered, they simply refuse to cooperate, and seem to prefer to hack their way around everything, instead of solving it structurally. For example, the BSP should define a machine feature HAS_TRANSCODING, so all the code has to do is to check if this feature is enabled. And not check if it's an ET10000, a VU Duo2, a Mutant HD2400, and a handful of others. Because this means code changes every time a new box comes to market.

 

With the correct BSP, that new box would compile and be operational with all required features directly.

But you still require to detect what type of feature the drivers are offering. Especially the ones which are no perfect.

You cannot assume everything is done properly in the drivers and to start including

features which are sub-par with other boxes. So not sure where is the final benefit.

Or you only provide support to one type of boxes which have their drivers meeting the standard or done in certain way you can detect.

How is this working for all the other vendors ?  Not all the vendors have a team specialized in driver producing and testing.

You are only trying to scale up Openpli so that only the worthy vendors can approach it. Interesting but from android development experience is somehow pointless.

You are not google Android. Even Samsung is cutting corners sometimes.

Edited by pop_eye, 23 November 2015 - 18:34.

[littlesat]

You hit the point... Basically the community should refuse these work
a rounds so the manufacturiers will fix their drivers instread of the community is adding work a rounds alias dirty Fixes. But not everhyone in the community seems not to understand this and this may gives me the feeling that some instead to support as much als possible instead of cleaning up and improve stuff.... We should expect failures should be solved where they belong.. Manufacturers which cannot fix this should not profit from this free community... And regards Samsung and android... Samsung as manufacturen makes it functional!

Edited by littlesat, 23 November 2015 - 19:03.

[WanWizard]

But you still require to detect what type of feature the drivers are offering. Especially the ones which are no perfect.
You cannot assume everything is done properly in the drivers and to start including
features which are sub-par with other boxes. So not sure where is the final benefit.

We don't really care.
 
The manufacturer makes the BSP, and if the BSP (or the drivers or the box) is crap, we stop building images for that box. We are not in the business of making money for manufacturers, distributors and vendors. It is as simple as that. If they want an OpenPLi image for their hardware, they have to put some effort in.
 

Or you only provide support to one type of boxes which have their drivers meeting the standard or done in certain way you can detect.

Eh, yes. Not our problem. We do this because we like to, not because we like people making huge sums of money from our free effort.
 

How is this working for all the other vendors ? Not all the vendors have a team specialized in driver producing and testing.
You are only trying to scale up Openpli so that only the worthy vendors can approach it. Interesting but from android development experience is somehow pointless.
You are not google Android. Even Samsung is cutting corners sometimes.

 

Their problem.

 

Or are you in the habit of buying a brand new car, and then accepting that the manufacturer refers you to the <your-brand> ownersclub to get the car services and to get new parts? Because the manufacturer hasn't got any dealerships and mechanics?

 

Weird that you accept that from a manufacturer you just bought a 600 euro STB from...

 

You miss the point that in no way are we obliged to make an image for a box or a manufacturer. Anyone can ask for an OpenPLi image, and if they follow the procedure they are accepted and we make an image. Like recently happened for Xsarius. And if they fail, we drop them as fast as we accepted them. We simply prefer not to spend out time fixing someone else's problems, our free time is too precious for that.

 

There is something going on in this area at time moment, for some boxes the manufacturer hasn't upgraded the BSP to a more recent kernel. So changes are these boxes won't see an OpenPLi-5 unless the manufacturer starts putting some effort in.

 

It's a big shame that these manufacturers get away with their attitude towards their customers, partly because of the fact people accept they should not expect anything from them after they bought it, people expect teams like us to help them out for free, and other teams keep hacking their way around the shit some manufacturers produce.

[pop_eye]

Weird that you accept that from a manufacturer you just bought a 600 euro STB from...

 

Obviously I don`t accept this. And this is the reason I try to "fix" my 4k problem using different hardware.

What many users don`t get is that they throw themselves in arms way without realizing it..thinking is all ok.

Also I agree, it should not be this way with manufacturers.

[WanWizard]

Exactly.

 

But unfortunately we are a bit "yelling in the desert" (I think the proper English translation is "voice in the wilderness" ) as they say here, nobody is listening, nobody is willing to work on solving this structurally, so there is no incentive for manufacturers to better themselfs.

 

As long as the open source community is willing to fix their bugs for free, so they can sell hardware and make a profit, why would they care?

[mamamia]

Thank you for this interesting thread! The PLi point of view as explained above seams to make sense and of course it would be great if manufacturers improve their coding style and invest more in better software & driver support. On the other side I believe especially hardware innovation manufacturers like vu+ that take the risk to release new bcm hardware (Solo2, Duo2 & now ARM Solo4k with (!) FBC Tuner before others) should also be supported by PLi because they have the "problem" that it`s a give and take between BCM and manufacturers like vu+ as well and its seams obvious that new hardware needs new software/drivers supplied also by bcm as well as the manufacturer itself. It feels as if DMM and others that take the hardware innovation road had similar issues with bcm in the past.

 

Furthermore from the customer point of view, dev and image design diversity is welcome and the Openatv approach with many different devs as well as many great designers working to improve is great because their dev and design focus is different to PLi as well as Vu+ focussed VTi. The videos below show for example how different VTi and OpenAtv look. OpenATV team helps make e2 look sexy out of the box. A more modern & mainstream focussed e2 without having to reconfigure everything yourself is important too. Openpli and VTi have a different focus and from my point of view lack a bit of mainstream Openatv sexyness. 

 

New updated install wizard with multi resolution mymetrix skin

Automatic satellite recognition

Picon feed with great varity
etc.

 

https://youtu.be/z9CqPQKT-OQ at 0:30min to look and avoid the flash procedure. 

https://youtu.be/H4SfsRLvwrI start at 4:50min to look and avoid the flash procedure. 

Edited by mamamia, 1 December 2015 - 13:21.

[WanWizard]

We don't really care about sexyness.

 

We care about the quality of the engine, not the colour of the car. Everyone is free to make skins for OpenPLi, and if they are up to scratch we will add them to the feeds. Or use an OpenPLi derived image that offers you the complete christmas tree...

[Erik Slagter]

We have quite some users that begun with OpenATV and switched over. Because in the end, functionality always wins from looks.

Edited by Erik Slagter, 1 December 2015 - 15:22.