I had been working on getting HDMI working on a custom board with a 3.10.52 Kernel and Boundary Devices Ubuntu Trusty and I had noticed what I thought was the ability to mirror LVDS to an HDMI mirror, but now I think it was just an anomaly where both outputs were active and displaying the same image. I have LVDS setup as dual mode since I only have LVDS1 connected.
Is it possible to have an X11 HW accelerated LVDS and have it mirrored to an HDMI display?
Based on testing it looks like I can (w/ the current BSPs and Vivante X Drivers):
- Setup both LVDS & HDMI drivers to properly load and have one X11 HW Accelerated Display - Either LVDS or HDMI and have the other be available as a frame buffer device for say gstreamer pipeline.
- Setup both LVDS & HDMI drivers to properly load and use an Xorg.conf to have dual displays - In this case any HW acceleration (say calling glxgears) causes X to crash. Per reports on the forums that is basically the expected state based on the abilities of the current BSP/Vivante Driver X support a single accelerated display.
- Setup an anomaly condition where the HDMI is partially setup but it is not fully loaded and have the LVDS driver fully loaded. In this case based on settings both LVDS and HDMI outputs are both active and display the same image, but one will be distorted. The output that is not distorted is based on wether RGB24 or RGB666 was specified and by the device listed was first.
Background:
If I turn off I2C for the HDMI and properly setup a DTB for HDMI and LVDS, I can get both LVDS and HDMI output to be active by specifying both in the Kernel boot arguments
- Only fb0 and fb1 exist in /dev and sysfs => Appear to be the frame buffers for the LDB driver
- HDMI output will be on, but the driver will not fully load and create fb2. Items like HDMI Audio will complain about starting HDMI Video first
- Which ever device is specified first seems to drive the RGB24 or RGB666 setting. That setting will determine which display is distorted
- Since HDMI does not fully load, it appears the display resolution of the LVDS will used
If I turn I2C on for HDMI, I can make HDMI or LVDS act as the primary display and it appears I can use the other as a frame buffer device.
- Both outputs will be active.
- I see fb0, fb1, and fb2 and there are no warnings from HDMI Audio about loading HDMI Video first
- The primary screen will be the first screen declared in the boot arguments
- At least for my current monitor, 1024x768 is not a listed mode and as such HDMI ends up being set to 1280x1024 if I try 1024x768. Despite it accepting 1024x768@60 in the anomaly mode. If I specify 1920x1080, it will set to that.
- Creating an Xorg.conf will allow dual displays, but HW acceleration will crash X. I had some mouse related issues, but those are probably solvable with a bit more work Xorg.conf work.
I have not tried using the "separate view" for LVDS and setting up the anomaly on one and using the HDMI RGB24 setting, but I would expect I would see the same results where the HDMI and LDB driver properly load. One used as the primary display and other LVDS available as a framebuffer device.
I guess the other thing I wonder is if it is possible to do an image capture on one display output and use it as an input for another screen.
Hi Thomas,
The best approach to do this task is changing the backend to Wayland or FB and use the multi_buffer variable , if the backend is X11, it is through Xserver. you will need to change it. there is no any specific example for doing this.
Regards
Hi,
Thanks for the response I will have to look into Wayland when I have a chance. It sounds like the short answer is that it is not supported via X11. Though we are tied to X11 at the moment.
We need some of the advantages of a windowed environment and all that is built around X to go to a straight FB solution. If we have time to take a step back, Wayland may be an option if we have time to validate we can replicate a lot of functionality we have. We currently leverage X to support a number things like bezel button interactions and have tested HW accelerated Qt 5.5 integration against it as well.
Thanks,
Aaron