Linux/AM5728: Separating the LCD and HDMI display buffers

Some additional information (4.9.x kernel 4.00.00.04 SDK) trying to walk through the DSS users guide and problems I'm running into:

1) I can find no setting for number of CRTCs. The Kconfig files only show CRTC for the exynos and KMS drivers.
2) It isn't clear in the OMAP2+ Display Subsystem support menu as to what display corresponds to what DSS output. We need the TV and VIDEO1 outputs, but the menu only shows:

--- OMAP2+ Display Subsystem support │ │
│ │ [ ] Debug support │ │
│ │ [ ] Debugfs filesystem support │ │
│ │ [*] DPI support │ │
│ │ [*] VENC support │ │
│ │ [*] HDMI support for OMAP4 │ │
│ │ [*] HDMI support for OMAP5 │ │
│ │ [*] SDI support │ │
│ │ [*] DSI support │ │
│ │ (0) Minimum FCK/PCK ratio (for scaling) │ │
│ │ [*] Sleep 20ms after VENC reset

There is nothing in the users guide that discusses how to configure the video multiplexer to have the VIDEO1 pins muxed to the VIDEO1 output instead of the TV output (HDMI).

When responding keep in mind this summary of our requirements:

1) Separate frame buffers for the HDMI and LCD displays
2) The LCD on the video1 pins requires the DSS mux to be configured so that it receives LCD1 channel output.

Still struggling with this. The DSS users documentation is out of date and there have been a lot of changes made. The kernel configuration options such as number of CRTCs has been removed.

So far I've found the omapdrm.displays setting from a patch I came across:

patchwork.kernel.org/.../

Setting the kernel command with omapdrm.displays=0,1 appears to have separated the HDMI and LCD and LCD is associated with the /dev/fb0 framebuffer.

But there isn't a second frame buffer setup for the HDMI. The omap_drv.c code implies that num_crtcs internally tracks the number of entries in the .displays setting so I think the argument I'm using should end up setting num_crtcs to 2 but I still only see a single frame buffer with omapdrm.0

How do I get a framebuffer allocated for the HDMI?

Thanks.

Can anyone offer any help with this?

Chris, I apologize for the delay. Our key person for this issue has been unavailable. I'm looking into it now and we'll follow-up.

Excellent, thanks for the follow up.

Chris Welch66 said:

Still struggling with this. The DSS users documentation is out of date and there have been a lot of changes made. The kernel configuration options such as number of CRTCs has been removed.

No need for kernel configuration options for CRTCs anymore, the driver decides the number itself.

Chris Welch66 said:

But there isn't a second frame buffer setup for the HDMI. The omap_drv.c code implies that num_crtcs internally tracks the number of entries in the .displays setting so I think the argument I'm using should end up setting num_crtcs to 2 but I still only see a single frame buffer with omapdrm.0

Please provide bigger picture on what you are trying to do. Do you need fbdev for your use case or DRM.

We do not support fbdev anymore. By default, in recent kernel fbdev emulation is supported only on single screen. If you want multiple /dev/fbX devices, you need to go to omapfb driver and fix/improve the work by your self. Also note that, when you have fbdev emulation, and fb console, the fbdev makes sure that the DRM crtc, on which the fbdev is shown, is enabled. So if you have fbdev disabled, or fbdev only on one of the displays, a DRM app needs to make sure that the crtcs it uses are configured and enabled. 

We have and LCD and HDMI display on the product.

The LCD is a 2.5" touch panel on the front.  The displays operate independently.

We have to run X-11 on the HDMI as the product has a large application base.  This is a hard requirement.  

The LCD probably doesn't need to run X, but I'll have to chat with folks about it, we might be able to go to DRM for the LCD.

  If I understand things correctly, I don't think we have a choice give the X-11 requirement.

Questions:

1) My understanding is that we need frame buffer support to run X-11, is that correct? If not, how is it done via DRM?

2) I've been able to get the LCD separated and onto the emulated frame buffer, but I haven't been able to do the opposite (HDMI associated with the emulated frame buffer, LCD separated). So what do I need to do to setup a configuration such that the LCD is DRM and the HDMI uses the fbdev emulation?

Thanks

I've confirmed that we can use DRM for the LCD.

Can you please provide assistance as to how the configuration should be done such that the HDMI utilizes the emulated frame buffer and the LCD can use DRM?

Our LCD is compatible with the EVM LCD example, we use this as our device tree spec:

lcd0: display {
compatible = "osddisplays,osd070t1718-19ts", "panel-dpi";

label = "lcd";

backlight = <&lcd_bl>;

enable-gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>;
panel-timing {
clock-frequency = <6500000>;
hactive = <320>;
vactive = <240>;
hfront-porch = <20>;
hback-porch = <68>;
hsync-len = <2>;
vback-porch = <18>;
vfront-porch = <4>;
vsync-len = <2>;
hsync-active = <0>;
vsync-active = <0>;
de-active = <1>;
pixelclk-active = <1>;
};

port {
lcd_in: endpoint {
remote-endpoint = <&dpi_out>;
};
};
};

&dss {
ports {
#address-cells = <1>;
#size-cells = <0>;

dss_port: port {
dpi_out: endpoint {
remote-endpoint = <&lcd_in>;
data-lines = <24>;
};
};
};
};

However, this associates the LCD with the emulated frame buffer. How do we set this up so it is on a separated CRTC from the emulated frame buffer?

Chris Welch66 said:

1) My understanding is that we need frame buffer support to run X-11, is that correct? If not, how is it done via DRM?

X11 has different X drivers. There's fbdev driver that needs fbdev backend and then there are few drivers using DRM, of which maybe the most relevant is the standard "modesetting" driver which is included in the main X server (anything relatively recent X). Xorg config file can be used to choose the driver used.  

If you use X driver that uses DRM, and you want X on both HDMI and LCD things should work fine. However, if you don't want X on the LCD, things geet mote complex. DRM app can't be used to draw to the LCD, because the X server has already reserved the DRM device. In that case the options can be -

 

1) Hack the driver so that it creates separate fbs for both displays.

And then run fbdev X on the ine, and the custom stuff on the other. 

 

2) Run modesetting X on the HDMI screen, while having the fbdev on the LCD. Some changes to X are possibly needed so that X will not turn off the fbdev when it's starting.

Note that  there's no X11  support on PLSDK. 

Ok, I've been using the omap driver (fb based) for the X-11 configuration, but will have a look at modesetting driver.

We can handle using X-11 on the LCD so I'll pursue your suggestion of the modesetting DRM driver and running X on both displays .

By the statement:

"If you use X driver that uses DRM, and you want X on both HDMI and LCD things should work fine"

Does this mean the displays are independent or the displays are mirrored?

I built the libdrm materials and I was able to get a test pattern up on our LCD (using omapdrm driver):

./modetest -s 31:320x240

and on the HDMI

./modetest -s 36:800x600

However, I'm not able to simultaneously run both commands, I get a permission denied error even running as root. I assume this has something to do with what you mentioned " because the X server has already reserved the DRM device", but I don't understand as these are separate devices, why does one get locked out when the other is in use?

X is seeing the DRM devices:

[ 1037.412] (II) xfree86: Adding drm device (/dev/dri/card0)
[ 1037.413] (II) xfree86: Adding drm device (/dev/dri/card1)

but the modesetting driver doesn't work:

[ 1324.483] (II) modesetting(G0): using drv /dev/dri/card1
[ 1324.483] (WW) Falling back to old probe method for modesetting
[ 1324.483] (EE) No devices detected.
[ 1324.483] (EE)
Fatal server error:
[ 1324.483] (EE) no screens found(EE)

I tried to get modesetting to use the /dev/dri/card0 drm device using the "kmsdev" option, but it still uses /dev/dri/card1

I searched through the drivers and there is one I experimented with a while back that claims to be DRM, the armada-etnaviv so I launched it and X does start, but again it is on both the LCD and HDMI. However, the logs indicate it is using DRM access:

[ 1484.329] (II) armada(0): Added screen for KMS device /dev/dri/card1
[ 1484.329] (WW) Falling back to old probe method for armada
[ 1484.329] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[ 1484.329] (II) armada(0): hardware: omapdrm
[ 1484.329] (**) armada(0): Depth 16, (--) framebuffer bpp 16
[ 1484.329] (==) armada(0): RGB weight 565
[ 1484.329] (==) armada(0): Default visual is TrueColor

Oddly, it ignores /dev/dri/card0 and the armada driver doesn't appear to have an option to specify an alternate KMS device.

So back to the original question, now that I have it working with DRM, how do I separate the displays, I.e. each running their own X session?

Some additional news. I tried turning on debug with the modesetting driver and it started to work. I commented out the debug option and it continued to work. Go figure.

The modesetting driver uses /dev/dri/card0, but has the same issue as the armada driver in that the same X session is on both the LCD and HDMI.

I ran some tests from processors.wiki.ti.com/.../Graphics_Display_Getting_Started_Guide and the tests suggest the displays are separated.

Sorry, I just noticed I'm using a different kernel when I did this. There appears to be a problem with the other kernel to use the modesetting driver, I'll check the configuration file for it. Note that with the kernel where it works, there is only one CRTC, /dev/dri/card0. The device tree is setup the same way for the LCD for both kernels.

modetest shows two CRTCs with this setup and the omap tests appear be able to handle the displays separately.

I suspect the separate display operation has to be done via the modesetting driver so I'll look into multi head operation with it.

Again, any suggestions are appreciated to get the displays separated under X.

If I'm understanding things properly, I need a DRM driver that allows specification of the CRTC in the device configuration section of xorg.conf in order to get separate display (effectively multi head operation).

I don't see this ability in the existing drivers I'm looking at (modesetting and armada). It looks like I'd have to work on the driver to add an option that allows the selection of a specific CRTC for the device section of the xorg.conf configuration.

modesetting only allows the option of selecting a KMS device, but the KMS device is related to both of my displays so it provides no separation.

However, it seems to me that it is more complex than this because you can't have two separate drivers using the same KMS. The driver would have to be implemented in such away that it runs as a single driver, but can support separate xorg.conf device CRTC option specifications.

Alternately an approach would be someway that the screen section of xorg.conf could reference a CRTC within the xorg.conf declared device.

That seems to be a heavy stretch to simply get separate displays. I'll spend some more time looking at this, but I'm thinking this isn't a viable approach for us and I should look at setting up a separate frame buffer driver for the LCD.

Does this sound correct?

Chris Welch66 said:

there is only one CRTC, /dev/dri/card0.

You are mixing up DRM card, crtcs, and displays. We have a single DRM card for DSS. That card device has multiple crtcs, and each of those go to a different display. When a app uses a card device, that card is then reserved, and all the crtcs and panels for that card. 

That's the reason for "However, I'm not able to simultaneously run both commands". You can do below to run a single modetest, which sets up both displays:

./modetest -s 31:320x240 -s 36:800x600

The second card you are seeing is SGX (hardware accelerator for 3D graphics) It's also a DRM card device, even if it doesn't have any display outputs. When there are multiple DRM devices, it's "random" which one ends up as card0 and which one card1. So a proper application will go through the cards and find the one that's it's interested in. 

Not sure why you are getting mirrored output on modesetting X driver. Below config is reported to have separate one by default on X.Org X Server 1.19.3.  

Section "Device"

              Identifier            "Configured Video Device"

              Driver                  "modesetting"

              Option                "SWcursor" "True"

              Option                "ShadowFB" "False"

              Option                "kmsdev" "/dev/dri/card0"

        Option                       "AccelMethod" "None"

EndSection

 We are not X expert here do can't give advice on how to configure X wrt display outputs. These are standard stuff. At runtime one can do all kinds of X display configurations with the "xrandr" tool. But to make it a fixed config, the X config file can be used, which has sections for screens etc.There should be plenty of information about it on net. 

Check below to learn how to swap the primary display (fbdev on HDMI)

Thanks that was helpful to clarify my understanding and the second /dev/dri/card. I see now that card0 was skipped over because it is the SGX accelerator and has no outputs, so it would be ignored.

I have made some progress and with an xorg.conf:

Section "Monitor"
Identifier "HDMI"
Option "PreferredMode" "1920x1080"
EndSection

Section "Monitor"
Identifier "LCD"
Option "PreferredMode" "320x240"
EndSection

Section "Device"
Identifier "DRM Device 0"
# Driver "armada"
Driver "modesetting"
# Option "HWcursor" "false"
Option "Monitor-HDMI-0" "HDMI"
Option "Monitor-None-0" "LCD"
EndSection

I now have the DRM outputs HDMI-0 and None-0 (obtained via the xrandr report) associated with the corresponding monitors, although X still renders on both simultaneously treating them as a single display.

I think this can lead to a solution so I'll continue pursuing it, however, if you do get an idea as to why both outputs are rendering from the same thing and how to separate them, I'd appreciate it.