80 replies to this topic

[serdeliuk]

Hello,

 

I am trying to display X11 desktop over the fbdev driver on /dev/fb0 on solo4k and it seems to be more difficult that i thought.

It seems to have 3 buffers instead of only one, or I am missing something.

I have executed cat /dev/urandom > /dev/fb0 to fill entire buffer with random pixels, after that i used showiframe to display an image on tv, but the image appear under the random pixels, after that i started x11 desktop and an xterm window.

For my surprise the zone of the window cleared the random pixels from and reveal the image under displayed by showiframe, but not the actual window content, if i start x11vnc and connect with vnc client and move the mouse, the mouse trail clear the random pixels but not actually show any mouse, also if i move the xterm window, pixels are cleared, but not display the window content.

 

I decided to use grab to grab video buffer, osd buffer and both together and i had a surprise,

- the image from video buffer is completely black

- the image from osd buffer contain the xterm window on a black screen or random pixels with zones cleared by mouse trails or by moving xterm window.

- the image from both video and osd contain random pixels, all cleared pixels from mouse trails or moving window but no window content.

- in my tv screen i still have the initial image with random pixels over.

 

Please somebody guide me on how to properly display the x11 desktop over fb0 or other device.

 

Attached 4 pictures to let you see what i am actually facing.

 

Best regards,

 

 

Marc

Attached Files

•  actual_tv_screen.jpg   130.04KB   11 downloads
•  osd_and_video_fb.jpg   263.84KB   9 downloads
•  osd_only_fb.jpg   289.1KB   12 downloads
•  video_only_fb.jpg   13.27KB   10 downloads

Edited by serdeliuk, 6 April 2016 - 23:26.

[MiLo]

I thought it only had 2 buffers, one OSD and one Video. Each runs at its own resolution, the chip blends them together in hardware.

The OSD can be panned or double-buffered.

The OSD uses ARGB pixels, the "A" is the transparency and determines how much of the video shows through. Writing random data to the fb will thus cause the pixels to have random transparency as well.

[MiLo]

Enigma2 does some ioctl to the framebuffer to trigger blending the OSD. I'm not sure how it works, but it needs to be called after changes to the OSD data, otherwise the changes will take longer to actually appear on the screen. I experimented with a QT-embedded video driver for the framebuffer and that worked well. Without the ioctl the mouse movement was "choppy".

Edited by MiLo, 7 April 2016 - 06:34.

[serdeliuk]

Hi,

 

Thanks, i suspected that i need to trigger something in order to bring the OSD content over VIDEO buffer, but the /dev/fb0 seems to be a plain device without ioctl, so the command should be addressed elsewhere.

 

I wonder why the fbdev driver put the X11 Desktop content on the OSD instead of VIDEO and how this behaviour can be changed? This is strange, because the start of the fb0 buffer is on the TV screen, which mean the fbdev driver struggle to put the content of the X11 Desktop in the middle of the buffer instead to simply put at the start of the buffer.

 

The "cat /dev/urandom > /dev/fb0" command start to write random pixels instantly on the screen and after the TV screen is filled it continue to run for the same amount of time until it tell "cat: write error: No space left on device", if i stop the command "ctrl+C" the OSD buffer will not be filled with random pixels.

So it seems that the /dev/fb0 device is the same device for both video and OSD and have the same size for both, probably the ram buffer is split in half, and with a driver command the second one is overlaid over the first one.

Also, there is a strange behaviour in the output of the grab command with "-o" or "-v" parameters versus no parameters (ie. both video and osd together)

- Only OSD buffer "-o" will grab also my x11 desktop xterm window

- Only VIDEO buffer "-v" will grab a black screen, even on my TV screen is a colour image.

- No parameters passed to "grab" command will grab a strange screen with a ghost like shadow with random pixels over the black screen but on the area where the xterm window is the random pixels are missing.

- On my TV screen is a colour image during all those operations which is missing...., because of that and because the xterm window is missing as well from grab command i think there a 4 levels of that /dev/fb0 device or it's ram buffer.

 

Very strange, i wonder if somebody tried till now to run X11 desktop on this kind of devices?

 

 

Best regards,

 

 

Marc

[serdeliuk]

I forgot to mention, the ShadowFB option of the fbdev driver is disabled, to not have another buffer, so the X11 Desktop, over the x11vnc is the same as the image grabbed with "-o" parameter and have the same size and depth with on screen image.

[betacentauri]

Afaik there are 2 layers. First layer shows video. The second one (above the first layer!) is used for OSD. So if OSD is transparent then video is visible in the background.

Via /dev/fb0 you can only access OSD layer. Video layer is no framebuffer device. You can eg look into showiframe how to access the layer, but afaik you can only show MPEG video (or single I frames or other media content) in that layer.

[serdeliuk]

Hello,

 

Thanks, well, the grab tool take snapshots of VIDEO buffer as well as for the OSD one.

It is strange that could not get the background mvi which is for sure in video buffer, was placed there with showiframe, if i enable live video on the front panel lcd the image is there, without pixels indeed, but is there.

 

If the video buffer is not accessible through /dev/fb0 then probably somehow those random pixels arrived there by mistake? Because i can see them on my TV screen over the mvi image. Also there is a free space on the area where reside the xterm from X11 Desktop. So why those pixels get cleared on the TV screen where I move the xterm window, but does not show the xterm window content? This is very odd, even if there is not the video buffer, there is a strange behaviour showing random pixels, cleared by the xterm window, but not showing the xterm window content.

 

Is then there any driver to access the video buffer directly from X11 desktop? Currently i use the fbdev driver which seems to not do the job.

Or is there any way to display the entire content of the OSD layer? Not just random pixels.

 

Best regards,

 

 

Marc

[MiLo]

The horrible "grab" program does some DMA and memory access trickery, using undocumented hardware addresses. It may overlap with existing "real" memory when it does the DMA. Don't trust it. Trust what you see on the TV, that is what is really in there.

[MiLo]

Is then there any driver to access the video buffer directly from X11 desktop?

What parts of betacentauri's answer were unclear to you?

[Lost in Space]

Well on Dreamboxes the following xorg.conf (just rename it) works nicely.

 

Barry Allen even installs a fully running Debian with whatever xdesktop you want which you can (multi) boot like any other Image.

Attached Files

•  xorg.txt   1.7KB   13 downloads

Edited by gutemine, 7 April 2016 - 19:57.

[betacentauri]

You write random pixels to the OSD layer. Then you show xterm window on the OSD layer. So it's no surprise that the xterm window clears the pixels.
I guess it could be problem with colors or mode. Do you use 32bit color mode? Maybe byte order is different. I mean you use ARGB and the box uses BGRA or something like that.

How can I reproduce what you do?

[serdeliuk]

Hello,

 

Thanks, the provided xorg.conf do the same as mine, actually is almost the same only difference is the depth, mine is set on 24bit and the provided config is set on 16bit.

 

I understand that i wrote on the OSD layer, but even so, those random pixels are shown on the TV, more, the random pixels cleared by the xterm window should be replaced by the window itself, but this does not happen.

 

Lately i found that if i add to xorg.conf, in the screen section the following line

DefaultFbBpp 32

 

the window will show on the the TV, but with strange colours/texture, so indeed it seems to be something related to depth and color modes, i will play around with, thanks for sugetion.

 

Not sure how to reproduce on your side, i have builded xserver-xorg and installed from packages, actually i want to build meta-sdr with gqrx and run it on my solo4k

 

 

Many thanks,

 

 

Marc

[Lost in Space]

By switching to 16 bit you simply avoid the Alpha hassle.

 

Actual what you experience it is the simply RGB vs BGR endian thing, which is also easy to fix

 

fbset will for example allow you to switch the rgba bitmap values

Edited by gutemine, 8 April 2016 - 12:54.

[serdeliuk]

Hi,

 

Thanks, how i can fix this issue? Is there any video driver for xorg x11 to use /dev/dvb/adapter0/video0 instead of /dev/fb0 on solo4k?

Currently i found fbdev x11 driver to be able to use the osd layer, but probably should be also a driver for dvb video device, right?

 

Best regards,

 

 

Marc

Edited by serdeliuk, 8 April 2016 - 12:55.

[MiLo]

dvb video is NOT a framebuffer.

[Lost in Space]

If X11 would produce MPEG2 or MPEG4 you could use it - as it doesn't MiLo is right

 

Various X11 apps can use the video device when X11 is running, unless you want to keep your CPU very busy.

 

PS: DM7080 can play non HD Video without the video device directly to the Framebuffer as the 4 cores of the CPU are powerfull enough

 

PS: simply use fbset before starting X - in my case the Barry Allen init binary does the job when booting Debian. You can even run X while enigma2 is running btw. as DreamOS handles the Framebuffer endianess nicely and behaves accordingly.

Edited by gutemine, 8 April 2016 - 13:16.

[malakudi]

Does /dev/video support lossless H.264? If cpu is fast enough, a X11 driver that creates lossless H.264 on the fly could work - at least in lower resolutions.

[serdeliuk]

Hi,

 

All i want is to be able to output on the TV screen the X11 desktop, does not care if it is a framebuffer or direct video device.

It seems that the /dev/fb0 does the job, i will need to play with fbset then, to adjust the image, but i wonder if i can display the X11 desktop to the video device instead of the framebuffer device, but for that i will need a video driver for X11, right? 

 

Please do not forget that i have SOLO4K which have an ARM CPU, so currently i am limited to which software i can use.

 

Best regards,

 

 

Marc

[MiLo]

The video device is for "video", as its name suggests.

The framebuffer device is a framebuffer. Who would have guessed.

The X11 server renders onto a framebuffer. So a framebuffer is what you need.

What part of this is so difficult to understand?

What next? Want to display your video on the audio device?

[MastaG]

So just wondering.
If you setup xorg.conf correct (maybe with the help of fbset), you're able to display the desktop.
But is there also a video player out there which is able to use the /dev/video device for playing back mpeg2/4 and render to an x11 window? (I can imagine it only needs to make the surface transparant?).