3D APP run failed after add RandR support on imx6q

cancel
Showing results for 
Search instead for 
Did you mean: 

3D APP run failed after add RandR support on imx6q

Jump to solution
655 Views
Contributor III

Hi,

Recently, I am working on a imx6q based board. The software is ubuntu_oneiric_4.0.0.tgz and L3.0.35_4.0.0_130424_images_MX6.tar.gz.

Also I did the instructions on file xserver-xorg-video-imx-viv-3.0.35-4.0.0/Instructions_to_setup_X11_acceleration_on_Ubuntu.

Then I got the default X driver from /opt/freescale/pkgs/xserver-xorg-video-imx-viv-3.0.35-4.0.0.tar.gz on the LTIB environment, and found that we can not switch mode by command xrandr, such xrandr --output HDMI --mode 1280x720. Also if we run xrandr -q, there is only one mode printed.

So need to modify the X driver and to add the xrandr support.

I did the following modification:

1, In xf86OutputFuncsRec.get_modes,  I got HDMI's EDID from /sys/devices/platform/mxc_hdmi/edid and passed to X in order to get all the supported modes.

2, In xf86OutputFuncsRec.mode_set,  I used fb ioctl FBIOPUT_VSCREENINFO to set the new mode.

3, In DPMS API, I used blank or unblank to turn on or turn off the FB.

After that, it works well, after I run command xrandr -q, many modes have been printed out. Then I can  run command xrandr --output HDMI --mode 1280x720 to switch the current mode from 1920x1080 to 1280x720.

But if I run some 3D applications, such as glxgears and the attachment demo, it will always occur some errors, such as "segmentation fault". After GDB, I found the error will always happened when function  'eglSwapBuffers'  being executed. If I switch the mode back to 1920x1080, all the 3D applications will run normally.

Also I tried to add the following content to function xf86CrtcConfigFuncsRec.resize  to modify the window pixmap.

{

        /* Access the screen. */

        ScreenPtr pScreen = pScrn->pScreen;

        if (NULL == pScreen) {

                return FALSE;

        }

        /* Access the screen pixmap */

        PixmapPtr pScreenPixmap = (*pScreen->GetScreenPixmap)(pScreen);

        if (NULL == pScreenPixmap) {

 

 

                return FALSE;

        }

      pScrn->virtualX = width;

      pScrn->virtualY = height;

      pScrn->displayWidth = width;

        const int bytesPerPixel = (pScrn->bitsPerPixel + 7) / 8;

        const int stride = pScrn->displayWidth * bytesPerPixel;

        /* Resize the screen pixmap to new size */

        (*pScreen->ModifyPixmapHeader)(

                pScreenPixmap,

                width,

                height,

                -1,                     /* same depth */

                -1,                     /* same bitsperpixel */

                stride,                 /* devKind = stride */

                NULL);                  /* same memory ptr */

 

 

        return TRUE;

}

But the screen will display abnormal after switching mode, and the 3D app will also run failed.

It seems that I need to update more information in the RANDR driver. For example, function DRIGetDrawableInfo will update more HW private information to the 3D apps, how to modify it?

Could anyone can give some suggestion? Thanks in advance.

 

 

 

 

Original Attachment has been moved to: SimpleTriangle.c.zip

Original Attachment has been moved to: xorg.conf.zip

Original Attachment has been moved to: Xorg.0.log.zip

Labels (3)
Tags (4)
1 Solution
126 Views
Contributor III

Hi Michel,

I am so glad to tell you that the XRANDR driver developed by myself can work well with the new BSP release L3.0.35_4.1.0_130816. Both OpenGLES/VG applications can run normally after I used xrand command to switch the display mode. Although I do not need to wait for the XRANDR support from FreeScale, please still notify me when FreeScale's XRANDR is ready.

Thanks for your greatly help.

View solution in original post

9 Replies
126 Views
Contributor III

Actually using command xrandr to switch mode is necessary for many end-customers, as it is not so convenient for them to change the mode in Uboot“s bootargs by COM port. So are there any plans for FreeScale or Vivante to provide a X driver with RADNR support?

0 Kudos
126 Views
Contributor III

The problem  still alive !!!

0 Kudos
126 Views
NXP Employee
NXP Employee

Hi,

Freescale will implement Xard functionality sometime this year. (It's low priority)

I don't know the X driver that well but in the meantime maybe PrabhuSundararaj can give you some advice.

Michel

0 Kudos
126 Views
Contributor III

Hi,

Thanks for you kindly help.

Would you please notify me if the XRANDR supported in the imx6's release? Does it only support single display,or dual display, such as HDMI+LVDS?

About how long we need to wait for it, two months?

Thanks in advance!

0 Kudos
126 Views
NXP Employee
NXP Employee

Hi,

     I don't know what is the plan of how to support XRANDR, or if we even have one. It's probably on the list of future features to implement but that's it.

     I have asked our R&D department if we have hard dates or a plan to support this I'll let you know the answer.

Michel

126 Views
Contributor III

Hi Michel,

Thanks so much for your important information.

0 Kudos
126 Views
NXP Employee
NXP Employee

Hi,

We are still on the same page. R&D plans to implement XRANDR functionality this year but that is as far as they have gone.

Michel

0 Kudos
127 Views
Contributor III

Hi Michel,

I am so glad to tell you that the XRANDR driver developed by myself can work well with the new BSP release L3.0.35_4.1.0_130816. Both OpenGLES/VG applications can run normally after I used xrand command to switch the display mode. Although I do not need to wait for the XRANDR support from FreeScale, please still notify me when FreeScale's XRANDR is ready.

Thanks for your greatly help.

View solution in original post

126 Views
NXP Employee
NXP Employee

Sure, no problem. I just learned that implementing Xwayland would be the fates way to rotate in X11. We have a wayland backend so theoretically it can be done.

Michel

0 Kudos