• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 99 subscribers
  • Views 1271 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM3354: Display shift with DRM driver

Yuriy Y
Prodigy 110 points
Part Number: AM3354


Hi,

We have been using kernel 3.12 for a while, with FBdev display driver. We have a custon board with LVDS outpot. We use LVDS<->D-Sub converter to hook up a D-Sub display.

The image on the display is shifted right, so we used to use "fbset -left" command to shft it into position.

Now, we have switched to kernel 4.4, where there is a DRM driver insteda of FB. Of cource, "fbset - left" doesn't work any more.

I am therefore looking for a DRM equivalent of image shifting. I tried changing "hfront-porch" in my device tree, but that doesn't seem to make any effect.

I would be most greatful for some tips on how to set horizontal margins in DRM, please.

  • 0
    TI__Guru**** 393215 points
    Hi,

    What type of display is this? What is the display resolution you use?
  • 0 in reply to Biser Gatchev-XID
    Prodigy 110 points
    Hi Biser,

    It's just a regular office monitor with D-Sub input. It runs 1024x768. The monitor works fine when connected to a PC, but it appears that our LVDS-to-D-sub converter somehow shifts the picture to the side horizontally.

    I have setup device tree to work with LVDS output and set the resoltuion to native 1024x768. The image is there, but it is shifted to the right, and the right edge wraps around and appears on the left of the screen, if you know what i mean. Much like a half way scrolled camera film.

    As I say, previously we used fbset -left to remediate this, but under DRM we have no idea what the equivalent is.
  • 0 in reply to Yuriy Y
    Mastermind 8040 points

    Yuriy Y said:
    The image is there, but it is shifted to the right

    By how many pixels?

  • 0 in reply to Matthijs van Duin
    Prodigy 110 points

    If I connect a display panel to LVDS port on our custom board the image is alligned to the top left corner, which is correct.

    If we connect a desktop monitor through LVDS->D-Sub converter the image is shifted to the right by 767 pixels.

    Basically I am trying to find a DRM equivalent to "fbset -left 767", because adjusting "hfront-porch" does absolutely nothing :(

  • 0 in reply to Yuriy Y
    Mastermind 8040 points

    Yuriy Y said:
    If I connect a display panel to LVDS port on our custom board the image is alligned to the top left corner, which is correct.

    If we connect a desktop monitor through LVDS->D-Sub converter the image is shifted to the right by 767 pixels.

    That's a weird shift amount... My guess would be the monitor might be getting confused by the non-VESA-compliant timings from lcdc, while the LVDS panel probably doesn't even care about hsync/vsync but just relies on DE.

    Yuriy Y said:
    Basically I am trying to find a DRM equivalent to "fbset -left 767"

    I'm not sure what that fbset command used to do, but I'm guessing it introduces an offset between the framebuffer in memory and the scanout region?  It wouldn't be hard to hack this in, but I doubt it's available as built-in function by default... (In general, the legacy fbdev interface emulated by drm drivers is fairly basic.)

    Yuriy Y said:
    adjusting "hfront-porch" does absolutely nothing

    That is the expected result. Adjusting the (vertical or horizontal) front or back porch shouldn't have any visible effect, as long as it's within range of what the monitor supports.

  • 0 in reply to Matthijs van Duin
    Prodigy 110 points

    Thank you for this.

    Where would you suggest I start looking to hack it? Is that video driver? Or device tree?

  • 0 in reply to Yuriy Y
    TI__Mastermind 22946 points
    You can try setting DRM property CRTC_X to negative 767. You can set the property using drmModeAtomicAddProperty() API if your application is the owner of drm handle. Check this dual camera demo source code that's developed for AM437x/AM57x processor but the DRM API usage should hold good for AM335x processor too.

    git.ti.com/.../master

    Check the loopback.c file and grep for CRTC_X.
  • 0 in reply to Manisha Agrawal
    Mastermind 8040 points

    manisha said:
    You can try setting DRM property CRTC_X to negative 767.

    This will fail the bounds-checking performed in the kernel and result in EINVAL. Even if this weren't an issue, it will still fail because you're asking the kernel to position the framebuffer within the scanout region, which is not supported by LCDC.

    I think the intended result might be achievable by setting SRC_X to 767<<16 and sabotaging any bounds-check in the kernel that objects to it. Of course, it may be better to just find a suitable place to add "+= fb_offset" and declare fb_offset as a new module parameter, which would allow the display to be right immediately from boot. Doing it via the DRM api would cause the display to revert to its default as soon as the application that performed the configuration exits.