80 replies to this topic

[Lost in Space]

You are welcome to READ the C source.

[Erik Slagter]

It's guesswork, definately no documentation.

[Lost in Space]

What a great argument when 9X% of enigma2 ins not doumented outside of the source code ...

[Erik Slagter]

Yeah let's talk quality of code of enigma

 

But this is not about code quality. It's about enigma+drivers being written based on official documentation from a.o. Broadcom, documenation none of us have access to. The screen grabber happens to work, but there is no guarantee it will work when (mis)used as framebuffer.

[Lost in Space]

Please read you original post:

 

>>The memory where the actual data is stored for the picture is undocumented (NDA) and inaccessible.

 

Next you want to convince me that it is inaccessible ....

[Erik Slagter]

There is nowhere a documented guarantee that the data will be accessible at every moment in time in a certain layout. I know for instance that Intel GPU's using a technique called tiling where the layout of the framebuffer is not always lineair, it changes dynamically. So diggin into system memory may seem to work for grabbing the contents, there is no guarantee at all it will work if using as a framebuffer.

 

But of course everybody is free to decide where to spend time on, even though there is really no guarantee for success.

[Lost in Space]

I will give you a final advice (take it or leave it as I personally don't care):

 

There were people insisting that things heavier than air can't fly ... until 2 bike mechanics proved them wrong.

 

I gave the OP at least advice  how to make things fly ... as I have flown that plane already years ago  ... Now it is his decision to decide whose advice is ... better.

Edited by gutemine, 17 April 2016 - 11:04.

[WanWizard]

The fact that proves Erik has a point is that grab more than occasionally fails the make a good screenshot, but returns a black screen, a half interleaved screenshot, or sometimes even random coloured lines through the image.

 

You would not have that if you would have had a documented interface, instead of just grabbing a piece of memory and hope for the best.

 

Your "advice" is totally besides the point, let's not start about how many people died thinking they could fly, in that analogy you're a potential murderer with your "advice"...

[Lost in Space]

The ioctl to halt the Video buffer are also well known and documented ... but of course grab doesn't use them as this is not the idea when you wuickly want a screenshot without interferring.

 

Anyway, it is only about people saying 'this is not possible' until somebody proves them wrong.

 

The REAL point would be that Broadcom uses the box system memory also for the video buffer, so a clever guy would realize that probably it would not be faster to peek and pooke it than the framebuffer memory reserved for it ....

 

Therefore the REAL argument against would be that you then lack all the nice video hardware functionality to get things (Video Memory Manipulation) there done FAST  ... and yes THESE are unknown ... NOT the Memory address size and pixel encoding - which was the piece of Erik's statement which needed correction - as it is simply wrong and NOT the real inhibitor.

 

Without that you could use the Video Memory only like another framebuffer layer - which would be useless as the latest chips already have more than enough.

Edited by gutemine, 17 April 2016 - 14:31.

[Rob van der Does]

As far I can see in e2 it is currently only used to fade in, sweep, move, turn the standard e2 menus's... In fact it is only anoying. I also understood vu has drivers for it but we do not use it and our e2 needs some patches, which were when I looked at them for the turn, swap, shift and sweep stuff not realy nice implemented. But of course for a kodie plugin it might still be helpfull...

For VU the OpenGL-drivers are indeed only used for menu-animation (awful, very awful indeed) and the Kodi-plugin (which has nothing to do with a sat-receiver.
No idea what more useful purposes there could be.

[MiLo]

Accessing the video buffer for GUI purposes is a pointless exercise, it uses a YUV color model, and isn't a simple rectangle, but arranged in tiles, with the color layers in two planes. If you were to use it, you'd have to compose images in system memory and then have the GPU translate them into the video buffer to get any decent performance, since you'll need 9 MAC operations for each pixel for the RGB-YUV conversion. And the quality will be poor since the video buffer usually also uses 4:2:2 encoding.

[Erik Slagter]

So in theory, if you'd really want to follow this route: use the OSD layer for the frame buffer and use the video ram for an Xv-like/vdpau/vaapi implementation, for watching video's efficiently.

 

But you never know if it's really going to work beforehand.

[Lost in Space]

You are really testing my temper .... this time I will NOT tell you what nonsense you wrote ... again.

[theparasol]

Why don't you make another timebombed proof of concept to amaze the community once more

[Lost in Space]

I strongly recommend NOT to annoy me .

[gorski]

Or what?

[serdeliuk]

He cannot tell you, because he will need to shoot you after.

 

Well, we should not fight , yet, well maybe after few beers or other strong spirits, i think all ideas are welcomed, even worse ideas could generate infos which could be used by the community.

 

So, i will be the first one which I will apologise by my "nervous" responses, and promise to behave

 

Best regards,

 

 

Marc

[gorski]

Besides, maybe these guys like a bit of spanking... after a few beers...

[serdeliuk]

Hahaha, after neck....

[Erik Slagter]

Or what?

He's going to fire another DOS-attack on the website. Very mature way to resolve conflicts.