Hi, I have now an omapdrm/X11 driver configured on Debian Jessie 8.2.
LCD works fine :)
There is only one small glitch during X11 startup (besides the „atomic“ kernel warnings):
(EE) BUG: triggered 'if (minval > maxval && mode == 1)' (EE) BUG: ../../Xi/exevents.c:2087 in InitValuatorAxisStruct() (EE) (EE) Backtrace: (EE)
And, I can see the HDMI port
root@gta04:~# ls -l /sys/devices/platform/omapdrm.0/drm/card0 total 0 drwxr-xr-x 3 root root 0 Jan 1 00:00 card0-HDMI-A-1 drwxr-xr-x 3 root root 0 Jan 1 00:00 card0-Unknown-1 -r--r--r-- 1 root root 4096 Jan 1 00:01 dev lrwxrwxrwx 1 root root 0 Jan 1 00:01 device -> ../../../omapdrm.0 drwxr-xr-x 2 root root 0 Jan 1 00:01 power lrwxrwxrwx 1 root root 0 Jan 1 00:00 subsystem -> ../../../../../class/drm -rw-r--r-- 1 root root 4096 Jan 1 00:00 uevent root@gta04:~# root@gta04:~# xrandr Screen 0: minimum 320 x 200, current 720 x 1280, maximum 2048 x 2048 None-1 connected 720x1280+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 720x1280 60.00*+ HDMI-1 disconnected (normal left inverted right x axis y axis) root@gta04:~#
but it does not work. Monitor reports no signal, status is „disconnected“ (independently of having the monitor connected before boot or after). I also can’t read the edid through /sys - so I think the driver is powered down.
root@gta04:~# ls -l /sys/devices/platform/omapdrm.0/drm/card0 total 0 drwxr-xr-x 3 root root 0 Jan 1 00:00 card0-HDMI-A-1 drwxr-xr-x 3 root root 0 Jan 1 00:00 card0-Unknown-1 -r--r--r-- 1 root root 4096 Jan 1 00:01 dev lrwxrwxrwx 1 root root 0 Jan 1 00:01 device -> ../../../omapdrm.0 drwxr-xr-x 2 root root 0 Jan 1 00:01 power lrwxrwxrwx 1 root root 0 Jan 1 00:00 subsystem -> ../../../../../class/drm -rw-r--r-- 1 root root 4096 Jan 1 00:00 uevent root@gta04:~#
root@gta04:/sys/devices/platform/omapdrm.0/drm/card0/card0-HDMI-A-1# ls -l total 0 lrwxrwxrwx 1 root root 0 Jan 1 00:01 device -> ../../card0 -r--r--r-- 1 root root 4096 Jan 1 00:01 dpms -r--r--r-- 1 root root 0 Jan 1 00:01 edid -r--r--r-- 1 root root 4096 Jan 1 00:01 enabled -r--r--r-- 1 root root 4096 Jan 1 00:01 modes drwxr-xr-x 2 root root 0 Jan 1 00:01 power -rw-r--r-- 1 root root 4096 Jan 1 00:01 status lrwxrwxrwx 1 root root 0 Jan 1 00:01 subsystem -> ../../../../../../class/drm -rw-r--r-- 1 root root 4096 Jan 1 00:01 uevent root@gta04:/sys/devices/platform/omapdrm.0/drm/card0/card0-HDMI-A-1# cat edid root@gta04:/sys/devices/platform/omapdrm.0/drm/card0/card0-HDMI-A-1#
So how can I enable the HDMI port? And it appears that a single X11 screen shares both potential outputs.
Can this be solved by xorg.conf or is it something else?
What should I try next? Compile the kernel with no LCD and check if HDMI only works?
BR, Nikolaus
On 09/29/2015 04:10 PM, Dr. H. Nikolaus Schaller wrote:
Hi, I have now an omapdrm/X11 driver configured on Debian Jessie 8.2.
LCD works fine :)
Do you have this stuff online somewhere yet ?
So how can I enable the HDMI port?
Have you tried setting omapdss.def_disp=hdmi on the kernel command line ?
Am 30.09.2015 um 08:13 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 29/09/15 23:32, aTc wrote:
So how can I enable the HDMI port?
Have you tried setting omapdss.def_disp=hdmi on the kernel command line ?
That only has effect when using omapfb.
Next, I will try to disable the lcd driver in DT (display aliases) and check if I can debug the issue.
BR, NIkolaus
Hi aTc,
Am 29.09.2015 um 22:32 schrieb aTc atc@k-n-p.org:
On 09/29/2015 04:10 PM, Dr. H. Nikolaus Schaller wrote:
Hi, I have now an omapdrm/X11 driver configured on Debian Jessie 8.2.
LCD works fine :)
Do you have this stuff online somewhere yet ?
Yes:
kernel variant (mainly changes to letux_defconfig):
http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/hns/wor...
precompiled
http://download.goldelico.com/gta04-kernel-new/hns/work/omapdrm/
rootfs (Jessie-LXDE w/o systemd):
http://download.goldelico.com/gta04-debian-lxde/ => 20150928-jessie-8.2-lxde.tbz
BR, Nikolaus
On 29/09/15 17:10, Dr. H. Nikolaus Schaller wrote:
but it does not work. Monitor reports no signal, status is „disconnected“ (independently of having the monitor connected before boot or after). I also can’t read the edid through /sys - so I think the driver is powered down.
Hmm, that hints to a HPD problem. This was on your custom board, not omap5 uevm? Have you verified the HPD pin? And the +5V that goes to the HDMI connector, supplied by the board?
If those are ok, then I guess easiest way is to add debug prints to the drivers/video/fbdev/omap2/displays-new/encoder-tpd12s015.c (presuming your board has tpd12s015/16), related to 'hpd_gpio'. Or, I guess you can see the value from debugfs's gpio file, if that's enabled in your kernel.
So how can I enable the HDMI port? And it appears that a single X11 screen shares both potential outputs.
Can this be solved by xorg.conf or is it something else?
I'm no expert on X, so I don't know. But I think xrandr can be used to configure the outputs, and there were lots of options for them.
Tomi
HI,
Am 30.09.2015 um 08:12 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 29/09/15 17:10, Dr. H. Nikolaus Schaller wrote:
but it does not work. Monitor reports no signal, status is „disconnected“ (independently of having the monitor connected before boot or after). I also can’t read the edid through /sys - so I think the driver is powered down.
Hmm, that hints to a HPD problem. This was on your custom board, not omap5 uevm?
My first test was on uevm where (almost) the same kernel configured for omapfb did show hdmi output.
Have you verified the HPD pin? And the +5V that goes to the HDMI connector, supplied by the board?
It is unlikely - but there could be a hidden change between kernel variants. Or initialization sequence/dependencies are different.
If those are ok, then I guess easiest way is to add debug prints to the drivers/video/fbdev/omap2/displays-new/encoder-tpd12s015.c (presuming your board has tpd12s015/16), related to 'hpd_gpio'. Or, I guess you can see the value from debugfs's gpio file, if that's enabled in your kernel.
So how can I enable the HDMI port? And it appears that a single X11 screen shares both potential outputs.
Can this be solved by xorg.conf or is it something else?
I'm no expert on X, so I don't know. But I think xrandr can be used to configure the outputs, and there were lots of options for them.
Without experimenting I think I have now understood how it works (not tested, so theory from reading the xranrd --help)
* drm assumes one or multiple graphics cards with one or multiple monitor outputs * omapdrm presents a single "card0" * with two outputs: None-1 and HDMI-1 * there is a single X instance (for each card) * there is a single frame buffer shared by all monitors * xrandr allows to arrange multiple monitors for this framebuffer - e.g. xrandr --output HDMI-1 --above None-1 - e.g. xrandr --primary HDMI-1 * so you get a big Screen where you can move windows from one to the other
So this should be the mechanism to enable/arrange the monitors. This also means that I do not need a second display/monitor section in my xorg.conf
That the HDMI is disabled appears to be unrelated.
BR and thanks, Nikolaus
On 29/09/15 17:10, Dr. H. Nikolaus Schaller wrote:
Hi, I have now an omapdrm/X11 driver configured on Debian Jessie 8.2.
LCD works fine :)
There is only one small glitch during X11 startup (besides the „atomic“ kernel warnings):
(EE) BUG: triggered 'if (minval > maxval && mode == 1)' (EE) BUG: ../../Xi/exevents.c:2087 in InitValuatorAxisStruct() (EE) (EE) Backtrace: (EE)
I don't see that on my X versions. I've attached my X log for reference.
Oh, one thing: I do use the HEAD of xf86-video-omap, not the latest released version (0.4.3). There are a few patches on top.
What should I try next? Compile the kernel with no LCD and check if HDMI only works?
You can try that, but also I still recommend getting some kernel modesetting test tool (modetest or something else). Testing with X is fine, but there are quite a few moving parts there. Having a simple KMS test is much better way to verify that the drivers/hardware is working.
Tomi
Am 01.10.2015 um 08:39 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 29/09/15 17:10, Dr. H. Nikolaus Schaller wrote:
Hi, I have now an omapdrm/X11 driver configured on Debian Jessie 8.2.
LCD works fine :)
There is only one small glitch during X11 startup (besides the „atomic“ kernel warnings):
(EE) BUG: triggered 'if (minval > maxval && mode == 1)' (EE) BUG: ../../Xi/exevents.c:2087 in InitValuatorAxisStruct() (EE) (EE) Backtrace: (EE)
I don't see that on my X versions. I've attached my X log for reference.
Well, I think I (or someone else) can debug later since it is completely X related and neither kernel nor driver.
Oh, one thing: I do use the HEAD of xf86-video-omap, not the latest released version (0.4.3). There are a few patches on top.
Well, I have simply installed the Debian Jessie 8.2 package. Haven't checked which source version they use.
What should I try next? Compile the kernel with no LCD and check if HDMI only works?
You can try that,
I have now tried but it does not appear to make any difference (unless I did something wrong). Are the display aliases used and significant in omapdrm mode? Or are they ignored?
but also I still recommend getting some kernel modesetting test tool (modetest or something else). Testing with X is fine, but there are quite a few moving parts there. Having a simple KMS test is much better way to verify that the drivers/hardware is working.
Have compiled modetest on the omap5 and it works.
And now - I do not exactly know what I have done differently - HDMI works.
In good resolution (1280x800) independently of the LCD resolution.
Modetest is nice... And debugfs for the hpd gpios as well:
root@gta04:~# cat /sys/kernel/debug/gpio | fgrep hdmi gpio-193 (hdmi_hpd ) in hi gpio-464 (hdmi_ct_cp_hpd ) out hi gpio-465 (hdmi_ls_oe ) out lo gpio-496 (modem_vbus_hdmi_powe) out hi root@gta04:~# xrandr Screen 0: minimum 320 x 200, current 720 x 1280, maximum 2048 x 2048 None-1 connected 720x1280+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 720x1280 60.00*+ HDMI-1 connected (normal left inverted right x axis y axis) 1280x800 59.81 + 119.91 1920x1080 60.00 50.00 59.94 30.00 25.00 24.00 29.97 23.98 1280x1024 75.02 60.02 1440x900 59.90 1366x768 59.79 1152x864 75.00 1280x720 60.00 50.00 59.94 1024x768 119.99 75.08 70.07 60.00 800x600 119.97 72.19 75.00 60.32 56.25 720x576 50.00 720x480 60.00 59.94 640x480 119.99 75.00 72.81 66.67 60.00 59.94 root@gta04:~#
It appears that they share a common big frame buffer (localhost:0.0) and effectively they are just two windows that can be moved around showing the same or different parts of the big "Screen".
It now works on both, the OMAP5 uevm and our own hardware. So my main target - to prove that the HDMI hardware is working as expected - is reached.
But the "atomic complete timeout" is a strange symptom. It only appears in DRM mode (even w/o X11) and I just have changed this:
diff --git a/arch/arm/configs/letux_defconfig b/arch/arm/configs/letux_defconfig index 3fa84ef..3d2cd83 100644 --- a/arch/arm/configs/letux_defconfig +++ b/arch/arm/configs/letux_defconfig @@ -2613,7 +2613,8 @@ CONFIG_DRM_I2C_NXP_TDA998X=m # CONFIG_DRM_EXYNOS is not set # CONFIG_DRM_UDL is not set # CONFIG_DRM_ARMADA is not set -# CONFIG_DRM_OMAP is not set +CONFIG_DRM_OMAP=m +CONFIG_DRM_OMAP_NUM_CRTCS=2 CONFIG_DRM_TILCDC=m CONFIG_DRM_TILCDC_SLAVE_COMPAT=y # CONFIG_DRM_STI is not set @@ -2626,15 +2627,15 @@ CONFIG_FIRMWARE_EDID=y CONFIG_FB_CMDLINE=y # CONFIG_FB_DDC is not set # CONFIG_FB_BOOT_VESA_SUPPORT is not set -CONFIG_FB_CFB_FILLRECT=y -CONFIG_FB_CFB_COPYAREA=y -CONFIG_FB_CFB_IMAGEBLIT=y +# CONFIG_FB_CFB_FILLRECT is not set +# CONFIG_FB_CFB_COPYAREA is not set +# CONFIG_FB_CFB_IMAGEBLIT is not set # CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set CONFIG_FB_SYS_FILLRECT=m CONFIG_FB_SYS_COPYAREA=m CONFIG_FB_SYS_IMAGEBLIT=m # CONFIG_FB_FOREIGN_ENDIAN is not set -# CONFIG_FB_SYS_FOPS is not set +CONFIG_FB_SYS_FOPS=m # CONFIG_FB_SVGALIB is not set # CONFIG_FB_MACMODES is not set # CONFIG_FB_BACKLIGHT is not set @@ -2670,9 +2671,7 @@ CONFIG_OMAP2_DSS_SDI=y CONFIG_OMAP2_DSS_DSI=y CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=0 CONFIG_OMAP2_DSS_SLEEP_AFTER_VENC_RESET=y -CONFIG_FB_OMAP2=y -CONFIG_FB_OMAP2_DEBUG_SUPPORT=y -CONFIG_FB_OMAP2_NUM_FBS=3 +# CONFIG_FB_OMAP2 is not set
# # OMAP Display Device Drivers (new device model)
What I have found is that the "atomic complete" disappears if I delete the panel (!) driver. And comes back if I restore. Deleting the hdmi driver does not make it disappear - so it is not a multi-monitor issue.
It is an issue of the panel driver if run in DRM mode.
Do you see anything critical in our panel driver (which works perfectly in omapfb mode):
http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=drivers/video/fbdev/om...
And touch screen is unuseable - looks as if something gets flooded by touch events:
[ 367.402778] omap_crtc_error_irq: 140957 callbacks suppressed [ 367.408760] [drm:omap_irq_handler [omapdrm]] *ERROR* tv: errors: 00008000 [ 367.415975] [drm:omap_irq_handler [omapdrm]] *ERROR* tv: errors: 00008000 [ 367.435473] [drm:omap_irq_handler [omapdrm]] *ERROR* tv: errors: 00008000 [ 367.442665] [drm:omap_irq_handler [omapdrm]] *ERROR* tv: errors: 00008000 [ 367.468852] [drm:omap_irq_handler [omapdrm]] *ERROR* tv: errors: 00008000
The effect is screen flicker and the X mouse cursor lagging 1-2 seconds behind.
Completely disappears in OMAPFB mode.
BR, Nikolaus Schaller
Am 01.10.2015 um 16:33 schrieb H. Nikolaus Schaller hns@goldelico.com:
Am 01.10.2015 um 08:39 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 29/09/15 17:10, Dr. H. Nikolaus Schaller wrote:
Hi, I have now an omapdrm/X11 driver configured on Debian Jessie 8.2.
LCD works fine :)
There is only one small glitch during X11 startup (besides the „atomic“ kernel warnings):
(EE) BUG: triggered 'if (minval > maxval && mode == 1)' (EE) BUG: ../../Xi/exevents.c:2087 in InitValuatorAxisStruct() (EE) (EE) Backtrace: (EE)
I don't see that on my X versions. I've attached my X log for reference.
Well, I think I (or someone else) can debug later since it is completely X related and neither kernel nor driver.
Oh, one thing: I do use the HEAD of xf86-video-omap, not the latest released version (0.4.3). There are a few patches on top.
Well, I have simply installed the Debian Jessie 8.2 package. Haven't checked which source version they use.
What should I try next? Compile the kernel with no LCD and check if HDMI only works?
You can try that,
I have now tried but it does not appear to make any difference (unless I did something wrong). Are the display aliases used and significant in omapdrm mode? Or are they ignored?
but also I still recommend getting some kernel modesetting test tool (modetest or something else). Testing with X is fine, but there are quite a few moving parts there. Having a simple KMS test is much better way to verify that the drivers/hardware is working.
Have compiled modetest on the omap5 and it works.
And now - I do not exactly know what I have done differently - HDMI works.
In good resolution (1280x800) independently of the LCD resolution.
Modetest is nice... And debugfs for the hpd gpios as well:
root@gta04:~# cat /sys/kernel/debug/gpio | fgrep hdmi gpio-193 (hdmi_hpd ) in hi gpio-464 (hdmi_ct_cp_hpd ) out hi gpio-465 (hdmi_ls_oe ) out lo gpio-496 (modem_vbus_hdmi_powe) out hi root@gta04:~# xrandr Screen 0: minimum 320 x 200, current 720 x 1280, maximum 2048 x 2048 None-1 connected 720x1280+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 720x1280 60.00*+ HDMI-1 connected (normal left inverted right x axis y axis) 1280x800 59.81 + 119.91 1920x1080 60.00 50.00 59.94 30.00 25.00 24.00 29.97 23.98 1280x1024 75.02 60.02 1440x900 59.90 1366x768 59.79 1152x864 75.00 1280x720 60.00 50.00 59.94 1024x768 119.99 75.08 70.07 60.00 800x600 119.97 72.19 75.00 60.32 56.25 720x576 50.00 720x480 60.00 59.94 640x480 119.99 75.00 72.81 66.67 60.00 59.94 root@gta04:~#
It appears that they share a common big frame buffer (localhost:0.0) and effectively they are just two windows that can be moved around showing the same or different parts of the big "Screen".
It now works on both, the OMAP5 uevm and our own hardware. So my main target - to prove that the HDMI hardware is working as expected - is reached.
But the "atomic complete timeout" is a strange symptom. It only appears in DRM mode (even w/o X11) and I just have changed this:
diff --git a/arch/arm/configs/letux_defconfig b/arch/arm/configs/letux_defconfig index 3fa84ef..3d2cd83 100644 --- a/arch/arm/configs/letux_defconfig +++ b/arch/arm/configs/letux_defconfig @@ -2613,7 +2613,8 @@ CONFIG_DRM_I2C_NXP_TDA998X=m # CONFIG_DRM_EXYNOS is not set # CONFIG_DRM_UDL is not set # CONFIG_DRM_ARMADA is not set -# CONFIG_DRM_OMAP is not set +CONFIG_DRM_OMAP=m +CONFIG_DRM_OMAP_NUM_CRTCS=2 CONFIG_DRM_TILCDC=m CONFIG_DRM_TILCDC_SLAVE_COMPAT=y # CONFIG_DRM_STI is not set @@ -2626,15 +2627,15 @@ CONFIG_FIRMWARE_EDID=y CONFIG_FB_CMDLINE=y # CONFIG_FB_DDC is not set # CONFIG_FB_BOOT_VESA_SUPPORT is not set -CONFIG_FB_CFB_FILLRECT=y -CONFIG_FB_CFB_COPYAREA=y -CONFIG_FB_CFB_IMAGEBLIT=y +# CONFIG_FB_CFB_FILLRECT is not set +# CONFIG_FB_CFB_COPYAREA is not set +# CONFIG_FB_CFB_IMAGEBLIT is not set # CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set CONFIG_FB_SYS_FILLRECT=m CONFIG_FB_SYS_COPYAREA=m CONFIG_FB_SYS_IMAGEBLIT=m # CONFIG_FB_FOREIGN_ENDIAN is not set -# CONFIG_FB_SYS_FOPS is not set +CONFIG_FB_SYS_FOPS=m # CONFIG_FB_SVGALIB is not set # CONFIG_FB_MACMODES is not set # CONFIG_FB_BACKLIGHT is not set @@ -2670,9 +2671,7 @@ CONFIG_OMAP2_DSS_SDI=y CONFIG_OMAP2_DSS_DSI=y CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=0 CONFIG_OMAP2_DSS_SLEEP_AFTER_VENC_RESET=y -CONFIG_FB_OMAP2=y -CONFIG_FB_OMAP2_DEBUG_SUPPORT=y -CONFIG_FB_OMAP2_NUM_FBS=3 +# CONFIG_FB_OMAP2 is not set
# # OMAP Display Device Drivers (new device model)
What I have found is that the "atomic complete" disappears if I delete the panel (!) driver. And comes back if I restore. Deleting the hdmi driver does not make it disappear - so it is not a multi-monitor issue.
It is an issue of the panel driver if run in DRM mode.
Do you see anything critical in our panel driver (which works perfectly in omapfb mode):
http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=drivers/video/fbdev/om...
After thinking about this in a background task, there maybe an important difference to other panel drivers (I don't see this issue on the OMAP3 with SPI/DPI panel).
We don't call in->ops.dsi->set_config() and in->ops.dsi->enable_hs() in the probe function.
They are called much later by a shell script (through a /sys interface) so that we are able to configure / tweak the panel timings to different panel setups.
Is there an implicit assumption what must be called in the panel driver's probe function?
And touch screen is unuseable - looks as if something gets flooded by touch events:
[ 367.402778] omap_crtc_error_irq: 140957 callbacks suppressed [ 367.408760] [drm:omap_irq_handler [omapdrm]] *ERROR* tv: errors: 00008000 [ 367.415975] [drm:omap_irq_handler [omapdrm]] *ERROR* tv: errors: 00008000 [ 367.435473] [drm:omap_irq_handler [omapdrm]] *ERROR* tv: errors: 00008000 [ 367.442665] [drm:omap_irq_handler [omapdrm]] *ERROR* tv: errors: 00008000 [ 367.468852] [drm:omap_irq_handler [omapdrm]] *ERROR* tv: errors: 00008000
The effect is screen flicker and the X mouse cursor lagging 1-2 seconds behind.
Completely disappears in OMAPFB mode.
BR, Nikolaus Schaller
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
I've just compiled your hns/work/omapdrm kernel, and things seem to work reasonably well.
I get the "atomic complete timeout" thing all over the place when using the omap5-pyra.dtb, but when using omap5-uevm.dtb things work fine (although a lot slower than when using the turbofb driver)
I also tried the xf86-video-omap driver, but there were no noticable differences between that and the debian xserver-xorg-video-omap package (no surprise, since the debian package comes from the same place)
Hi,
Am 02.10.2015 um 02:27 schrieb aTc atc@k-n-p.org:
I've just compiled your hns/work/omapdrm kernel, and things seem to work reasonably well.
I get the "atomic complete timeout" thing all over the place when using the omap5-pyra.dtb, but when using omap5-uevm.dtb things work fine (although a lot slower than when using the turbofb driver)
Thanks for cross-checking!
This is IMHO another hint towards our panel driver. That is where both significantly .dtb differ.
I also tried the xf86-video-omap driver, but there were no noticable differences between that and the debian xserver-xorg-video-omap package (no surprise, since the debian package comes from the same place)
Ok, good to know.
BR, Nikolaus
On 01/10/15 18:55, H. Nikolaus Schaller wrote:
After thinking about this in a background task, there maybe an important difference to other panel drivers (I don't see this issue on the OMAP3 with SPI/DPI panel).
I still have the DSI panel you sent me a while ago, and I can run v4.2 on omap5 uevm with both HDMI and the DSI panel working, plus X on top. And I haven't seen a single warning about atomic complete.
We don't call in->ops.dsi->set_config() and in->ops.dsi->enable_hs() in the probe function.
They are called much later by a shell script (through a /sys interface) so that we are able to configure / tweak the panel timings to different panel setups.
Is there an implicit assumption what must be called in the panel driver's probe function?
No. Probe is just for probing the device. But you must enable the video in enable(), and disable it in disable(). Otherwise DISPC will stay disabled after enable() call, and omapdrm expects to get vsync interrupts, which it never gets.
I'm not sure what kind of tweaks you do there, but if you want runtime hacking support, perhaps this is safer way:
xset dpms force off echo yourconf > /sys/panel/foobar xset dpms force on
That way the displays are turned off properly from X, then you reconfig the panel driver, and then enable it. Of course, if you change the resolution or such that way, things will surely get messy.
And touch screen is unuseable - looks as if something gets flooded by touch events:
[ 367.402778] omap_crtc_error_irq: 140957 callbacks suppressed [ 367.408760] [drm:omap_irq_handler [omapdrm]] *ERROR* tv: errors: 00008000 [ 367.415975] [drm:omap_irq_handler [omapdrm]] *ERROR* tv: errors: 00008000 [ 367.435473] [drm:omap_irq_handler [omapdrm]] *ERROR* tv: errors: 00008000 [ 367.442665] [drm:omap_irq_handler [omapdrm]] *ERROR* tv: errors: 00008000 [ 367.468852] [drm:omap_irq_handler [omapdrm]] *ERROR* tv: errors: 00008000
The effect is screen flicker and the X mouse cursor lagging 1-2 seconds behind.
Completely disappears in OMAPFB mode.
I see this also. In xorg config, "Device" section, do:
Option "HWcursor" "False"
If that's "true", X uses a video overlay for mouse cursor. Which is kind of unusable, as the legacy DRM API for configuring overlays is synchronous, and will lag everything as there's a _lot_ mouse events coming in.
Now, it still shouldn't cause sync lost errors from the HDMI output. I need to look at it.
Also, the pre v4.2 omapdrm had hacks to make the overlay config asynchronous, which kind of solved the hwcursor issue. But then caused other issues. So, the v4.2 behavior is kind of a regression.
Tomi
Hi,
Am 02.10.2015 um 09:03 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 01/10/15 18:55, H. Nikolaus Schaller wrote:
After thinking about this in a background task, there maybe an important difference to other panel drivers (I don't see this issue on the OMAP3 with SPI/DPI panel).
I still have the DSI panel you sent me a while ago, and I can run v4.2 on omap5 uevm with both HDMI and the DSI panel working, plus X on top. And I haven't seen a single warning about atomic complete.
Well, you might use the real panel driver (not the debug driver + shell script).
We don't call in->ops.dsi->set_config() and in->ops.dsi->enable_hs() in the probe function.
They are called much later by a shell script (through a /sys interface) so that we are able to configure / tweak the panel timings to different panel setups.
Is there an implicit assumption what must be called in the panel driver's probe function?
No. Probe is just for probing the device. But you must enable the video in enable(), and disable it in disable(). Otherwise DISPC will stay disabled after enable() call, and omapdrm expects to get vsync interrupts, which it never gets.
I'm not sure what kind of tweaks you do there, but if you want runtime hacking support, perhaps this is safer way:
xset dpms force off echo yourconf > /sys/panel/foobar xset dpms force on
That way the displays are turned off properly from X, then you reconfig the panel driver, and then enable it. Of course, if you change the resolution or such that way, things will surely get messy.
I will try. But the effect appears to be independent from using X and appears before X starts.
And touch screen is unuseable - looks as if something gets flooded by touch events:
[ 367.402778] omap_crtc_error_irq: 140957 callbacks suppressed [ 367.408760] [drm:omap_irq_handler [omapdrm]] *ERROR* tv: errors: 00008000 [ 367.415975] [drm:omap_irq_handler [omapdrm]] *ERROR* tv: errors: 00008000 [ 367.435473] [drm:omap_irq_handler [omapdrm]] *ERROR* tv: errors: 00008000 [ 367.442665] [drm:omap_irq_handler [omapdrm]] *ERROR* tv: errors: 00008000 [ 367.468852] [drm:omap_irq_handler [omapdrm]] *ERROR* tv: errors: 00008000
The effect is screen flicker and the X mouse cursor lagging 1-2 seconds behind.
Completely disappears in OMAPFB mode.
I see this also. In xorg config, "Device" section, do:
Option "HWcursor" "False"
Ah, that is very valuable to know.
If that's "true", X uses a video overlay for mouse cursor. Which is kind of unusable, as the legacy DRM API for configuring overlays is synchronous, and will lag everything as there's a _lot_ mouse events coming in.
Now, it still shouldn't cause sync lost errors from the HDMI output. I need to look at it.
Also, the pre v4.2 omapdrm had hacks to make the overlay config asynchronous, which kind of solved the hwcursor issue. But then caused other issues. So, the v4.2 behavior is kind of a regression.
It almost works now. But there is still some "lag" of intensive mouse move events. I can also see it on the omap3 device. The effect is funny: if I drag a selection rectangle and then move the mouse very fast around (while pressed), the rectangle makes nice figures :)
I have now also fixed a DT entry on the OMAP3 device with OPA362 (did need a reg = <0> property) and now have the VENC running. But it is in a strange state ("unknown connection"):
root@letux:~# xrandr --verbose xrandr: Output None-2 is not disconnected but has no modes Screen 0: minimum 320 x 200, current 480 x 640, maximum 2048 x 2048 None-1 connected 480x640+0+0 (0x43) normal (normal) 0mm x 0mm Identifier: 0x41 Timestamp: 38314 Subpixel: unknown Gamma: 1.0:1.0:1.0 Brightness: 1.0 Clones: CRTC: 0 CRTCs: 0 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: 480x640 (0x43) 22.153MHz -HSync -VSync *current +preferred h: width 480 start 504 end 512 total 520 skew 0 clock 42.60KHz v: height 640 start 644 end 646 total 648 clock 65.74Hz None-2 unknown connection (normal) Identifier: 0x42 Timestamp: 38314 Subpixel: unknown Clones: CRTCs: 1 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: root@letux:~#
BR and thanks, Nikolaus
On 02/10/15 13:00, H. Nikolaus Schaller wrote:
Hi,
Am 02.10.2015 um 09:03 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 01/10/15 18:55, H. Nikolaus Schaller wrote:
After thinking about this in a background task, there maybe an important difference to other panel drivers (I don't see this issue on the OMAP3 with SPI/DPI panel).
I still have the DSI panel you sent me a while ago, and I can run v4.2 on omap5 uevm with both HDMI and the DSI panel working, plus X on top. And I haven't seen a single warning about atomic complete.
Well, you might use the real panel driver (not the debug driver + shell script).
I'm not using any shell scripts. I'm using panel-r63311.c driver.
We don't call in->ops.dsi->set_config() and in->ops.dsi->enable_hs() in the probe function.
They are called much later by a shell script (through a /sys interface) so that we are able to configure / tweak the panel timings to different panel setups.
Is there an implicit assumption what must be called in the panel driver's probe function?
No. Probe is just for probing the device. But you must enable the video in enable(), and disable it in disable(). Otherwise DISPC will stay disabled after enable() call, and omapdrm expects to get vsync interrupts, which it never gets.
I'm not sure what kind of tweaks you do there, but if you want runtime hacking support, perhaps this is safer way:
xset dpms force off echo yourconf > /sys/panel/foobar xset dpms force on
That way the displays are turned off properly from X, then you reconfig the panel driver, and then enable it. Of course, if you change the resolution or such that way, things will surely get messy.
I will try. But the effect appears to be independent from using X and appears before X starts.
Yes, it will happen regardless of what you are running. The point is, the display should be turned off via the proper APIs, so that omapdrm is the one turning it off and on. If you turn it off by poking the panel driver directly, you'll have problems.
If that's "true", X uses a video overlay for mouse cursor. Which is kind of unusable, as the legacy DRM API for configuring overlays is synchronous, and will lag everything as there's a _lot_ mouse events coming in.
Now, it still shouldn't cause sync lost errors from the HDMI output. I need to look at it.
Also, the pre v4.2 omapdrm had hacks to make the overlay config asynchronous, which kind of solved the hwcursor issue. But then caused other issues. So, the v4.2 behavior is kind of a regression.
It almost works now. But there is still some "lag" of intensive mouse move events. I can also see it on the omap3 device. The effect is funny: if I drag a selection rectangle and then move the mouse very fast around (while pressed), the rectangle makes nice figures :)
I have now also fixed a DT entry on the OMAP3 device with OPA362 (did need a reg = <0> property) and now have the VENC running. But it is in a strange state ("unknown connection"):
Yes, there's no detection on VENC. So it reports the cable status as unknown. Are you saying it's not working?
Tomi
Am 02.10.2015 um 12:18 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 02/10/15 13:00, H. Nikolaus Schaller wrote:
Hi,
Am 02.10.2015 um 09:03 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 01/10/15 18:55, H. Nikolaus Schaller wrote:
After thinking about this in a background task, there maybe an important difference to other panel drivers (I don't see this issue on the OMAP3 with SPI/DPI panel).
I still have the DSI panel you sent me a while ago, and I can run v4.2 on omap5 uevm with both HDMI and the DSI panel working, plus X on top. And I haven't seen a single warning about atomic complete.
Well, you might use the real panel driver (not the debug driver + shell script).
I'm not using any shell scripts. I'm using panel-r63311.c driver.
This is what I have assumed. So you use a different panel driver which explains that only we see the issue.
But it is not extremely important since we want to provide a real panel driver (w/o shell script tricks) to the final product. The current setup was mainly to easily support development and debugging.
We don't call in->ops.dsi->set_config() and in->ops.dsi->enable_hs() in the probe function.
They are called much later by a shell script (through a /sys interface) so that we are able to configure / tweak the panel timings to different panel setups.
Is there an implicit assumption what must be called in the panel driver's probe function?
No. Probe is just for probing the device. But you must enable the video in enable(), and disable it in disable(). Otherwise DISPC will stay disabled after enable() call, and omapdrm expects to get vsync interrupts, which it never gets.
I'm not sure what kind of tweaks you do there, but if you want runtime hacking support, perhaps this is safer way:
xset dpms force off echo yourconf > /sys/panel/foobar xset dpms force on
That way the displays are turned off properly from X, then you reconfig the panel driver, and then enable it. Of course, if you change the resolution or such that way, things will surely get messy.
I will try. But the effect appears to be independent from using X and appears before X starts.
Yes, it will happen regardless of what you are running. The point is, the display should be turned off via the proper APIs, so that omapdrm is the one turning it off and on. If you turn it off by poking the panel driver directly, you'll have problems.
Ok, I see.
If that's "true", X uses a video overlay for mouse cursor. Which is kind of unusable, as the legacy DRM API for configuring overlays is synchronous, and will lag everything as there's a _lot_ mouse events coming in.
Now, it still shouldn't cause sync lost errors from the HDMI output. I need to look at it.
Also, the pre v4.2 omapdrm had hacks to make the overlay config asynchronous, which kind of solved the hwcursor issue. But then caused other issues. So, the v4.2 behavior is kind of a regression.
It almost works now. But there is still some "lag" of intensive mouse move events. I can also see it on the omap3 device. The effect is funny: if I drag a selection rectangle and then move the mouse very fast around (while pressed), the rectangle makes nice figures :)
I have now also fixed a DT entry on the OMAP3 device with OPA362 (did need a reg = <0> property) and now have the VENC running. But it is in a strange state ("unknown connection"):
Yes, there's no detection on VENC. So it reports the cable status as unknown. Are you saying it's not working?
I have not checked if it shows output signals but it also says that there are no modes (I had expected at least PAL and NTSC):
xrandr: Output None-2 is not disconnected but has no modes
But if there is no detection, is it possible to turn it completely off (our device shares the TVout with the headset microphone input so that we need some control to switch between both)?
Would xrandr --output None-2 --off turn off VENC?
root@letux:~# xrandr --output None-2 --off xrandr: Output None-2 is not disconnected but has no modes root@letux:~# xrandr --output None-2 --auto xrandr: Output None-2 is not disconnected but has no modes xrandr: cannot find preferred mode root@letux:~#
BR, Nikolaus Schaller
On 02/10/15 14:28, H. Nikolaus Schaller wrote:
I have not checked if it shows output signals but it also says that there are no modes (I had expected at least PAL and NTSC):
xrandr: Output None-2 is not disconnected but has no modes
But if there is no detection, is it possible to turn it completely off (our device shares the TVout with the headset microphone input so that we need some control to switch between both)?
Would xrandr --output None-2 --off turn off VENC?
root@letux:~# xrandr --output None-2 --off xrandr: Output None-2 is not disconnected but has no modes root@letux:~# xrandr --output None-2 --auto xrandr: Output None-2 is not disconnected but has no modes xrandr: cannot find preferred mode root@letux:~#
Ok. Perhaps it's broken. I'm quite sure VENC worked at some point. My beagle-xm has died some time ago, and they are not sold anymore. That was my only VENC device... =(
Tomi
Am 02.10.2015 um 13:33 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 02/10/15 14:28, H. Nikolaus Schaller wrote:
I have not checked if it shows output signals but it also says that there are no modes (I had expected at least PAL and NTSC):
xrandr: Output None-2 is not disconnected but has no modes
But if there is no detection, is it possible to turn it completely off (our device shares the TVout with the headset microphone input so that we need some control to switch between both)?
Would xrandr --output None-2 --off turn off VENC?
root@letux:~# xrandr --output None-2 --off xrandr: Output None-2 is not disconnected but has no modes root@letux:~# xrandr --output None-2 --auto xrandr: Output None-2 is not disconnected but has no modes xrandr: cannot find preferred mode root@letux:~#
Ok. Perhaps it's broken. I'm quite sure VENC worked at some point.
Yes, we also had it working...
My beagle-xm has died some time ago, and they are not sold anymore.
What a pity. Mouser did tell me a while ago that they await some shipment - but don't know when. Looks as if they are collecting preorders.
That was my only VENC device... =(
There are others: * OpenPandora (Michael has some remaining units) * GTA04 (we plan to build another small batch soon) * N900/RX51
But the cheapest (and best supported by mainline) would be the BB-XM.
Anyways, I will now focus on other topics.
BR, Nikolaus Schaller
Hi,
aTc has already started to switch to omapdrm in our official OS. It works - but is horribly slow, due to the missing closed source EXA module.
The driver doesn't tell where that module can be gotten from - any idea?
I hope it's not fixed to a certain kernel or X version and does work without any issues...
On 10/02/2015 04:25 PM, Michael Mrozek wrote:
Hi,
aTc has already started to switch to omapdrm in our official OS. It works - but is horribly slow, due to the missing closed source EXA module.
The driver doesn't tell where that module can be gotten from - any idea?
I hope it's not fixed to a certain kernel or X version and does work without any issues...
I've done a bit of digging, and it's just part of omap5-sgx-ddk-um-linux. Or more, used to be, since all the X11 EXA stuff was removed from it a while ago. The bits that were there look like they depend on the same kernel module as the 3d stuff, and some ancient xorg version ( ABI 11 vs the ABI 18 that's in debian now).
Am Sun, 4 Oct 2015 20:09:47 +0200 hat aTc atc@k-n-p.org geschrieben:
So... using opendrm without EXA is dog slow (3fps for a 360p YouTube video compared to full speed 720p when using omapfb) and the EXA part is closed source and can't be used...?
Did I understand that correctly? If that's true, then the OMAP5 is really, really crippled...
Tomi, do you know anything about that? Do you know if it's possible using omapdrm with EXA and a recent X server?
On 10/02/2015 04:25 PM, Michael Mrozek wrote:
Hi,
aTc has already started to switch to omapdrm in our official OS. It works - but is horribly slow, due to the missing closed source EXA module.
The driver doesn't tell where that module can be gotten from - any idea?
I hope it's not fixed to a certain kernel or X version and does work without any issues...
I've done a bit of digging, and it's just part of omap5-sgx-ddk-um-linux. Or more, used to be, since all the X11 EXA stuff was removed from it a while ago. The bits that were there look like they depend on the same kernel module as the 3d stuff, and some ancient xorg version ( ABI 11 vs the ABI 18 that's in debian now). _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Hi,
Right, anything related to SGX is problematic =).
We know this is a problem, and I just discussed about it with our GFX guy. EXA driver that uses SGX comes from IMG, and is closed source. TI is currently targeting Wayland in our official releases. However, there's a strong will to support also X and non-TI releases.
One interesting option is Glamor, which sounds like a much better alternative than closed source EXA driver. I have not looked at it yet, though.
Tomi
On 05/10/15 14:53, Michael Mrozek wrote:
Am Sun, 4 Oct 2015 20:09:47 +0200 hat aTc atc@k-n-p.org geschrieben:
So... using opendrm without EXA is dog slow (3fps for a 360p YouTube video compared to full speed 720p when using omapfb) and the EXA part is closed source and can't be used...?
Did I understand that correctly? If that's true, then the OMAP5 is really, really crippled...
Tomi, do you know anything about that? Do you know if it's possible using omapdrm with EXA and a recent X server?
On 10/02/2015 04:25 PM, Michael Mrozek wrote:
Hi,
aTc has already started to switch to omapdrm in our official OS. It works - but is horribly slow, due to the missing closed source EXA module.
The driver doesn't tell where that module can be gotten from - any idea?
I hope it's not fixed to a certain kernel or X version and does work without any issues...
I've done a bit of digging, and it's just part of omap5-sgx-ddk-um-linux. Or more, used to be, since all the X11 EXA stuff was removed from it a while ago. The bits that were there look like they depend on the same kernel module as the 3d stuff, and some ancient xorg version ( ABI 11 vs the ABI 18 that's in debian now). _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Am Tue, 6 Oct 2015 14:07:26 +0300 hat Tomi Valkeinen tomi.valkeinen@ti.com geschrieben:
Hi,
Right, anything related to SGX is problematic =).
Sadly, yes.
We know this is a problem, and I just discussed about it with our GFX guy. EXA driver that uses SGX comes from IMG, and is closed source. TI is currently targeting Wayland in our official releases. However, there's a strong will to support also X and non-TI releases.
That sounds good. notaz might be able to correct me here, but the problem is actually not the closed-source stuff from IMG (like the SGX driver, etc.), but another small binary blob that's used to communicate between X and the SGX driver.
With the Pandora, we didn't have that problem. SGX runs with any version of X, it's not dependent, but it seems that there's now one more closed source thing inbetween that prevents that.
Maybe notaz could explain it, as I'm not sure I understood it completely myself.
If that little part would be open (and I don't think that's from IMG), then we could simply load and use the SGX without any issues.
One interesting option is Glamor, which sounds like a much better alternative than closed source EXA driver. I have not looked at it yet, though.
Hm, but doesn't Glamor want to make use of the SGX, which wouldn't work if we can't access the SGX? :)
Tomi
On 05/10/15 14:53, Michael Mrozek wrote:
Am Sun, 4 Oct 2015 20:09:47 +0200 hat aTc atc@k-n-p.org geschrieben:
So... using opendrm without EXA is dog slow (3fps for a 360p YouTube video compared to full speed 720p when using omapfb) and the EXA part is closed source and can't be used...?
Did I understand that correctly? If that's true, then the OMAP5 is really, really crippled...
Tomi, do you know anything about that? Do you know if it's possible using omapdrm with EXA and a recent X server?
On 10/02/2015 04:25 PM, Michael Mrozek wrote:
Hi,
aTc has already started to switch to omapdrm in our official OS. It works - but is horribly slow, due to the missing closed source EXA module.
The driver doesn't tell where that module can be gotten from - any idea?
I hope it's not fixed to a certain kernel or X version and does work without any issues...
I've done a bit of digging, and it's just part of omap5-sgx-ddk-um-linux. Or more, used to be, since all the X11 EXA stuff was removed from it a while ago. The bits that were there look like they depend on the same kernel module as the 3d stuff, and some ancient xorg version ( ABI 11 vs the ABI 18 that's in debian now). _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
On 06/10/15 14:18, Michael Mrozek wrote:
That sounds good. notaz might be able to correct me here, but the problem is actually not the closed-source stuff from IMG (like the SGX driver, etc.), but another small binary blob that's used to communicate between X and the SGX driver.
There could be other libs that I'm not aware of, but afaik that is the EXA driver. Which is from IMG, and is closed. That driver uses SGX underneath.
With the Pandora, we didn't have that problem. SGX runs with any version of X, it's not dependent, but it seems that there's now one more closed source thing inbetween that prevents that.
Maybe notaz could explain it, as I'm not sure I understood it completely myself.
If that little part would be open (and I don't think that's from IMG), then we could simply load and use the SGX without any issues.
One interesting option is Glamor, which sounds like a much better alternative than closed source EXA driver. I have not looked at it yet, though.
Hm, but doesn't Glamor want to make use of the SGX, which wouldn't work if we can't access the SGX? :)
There are different bits and pieces here... Glamor uses OpenGL (ES I hope). If that's supported, then it should be possible to have X accelerated, removing the need for the closed source EXA part. So one less closed source problem involved.
Tomi
Hi,
For the general problem of slow X, we might be able to still use fbturbo on top of omapdrm's fb emulation. That was working at last year's gamescom, on TI's old 3.8 kernel.
On 10/06/2015 02:23 PM, Tomi Valkeinen wrote:
On 06/10/15 14:18, Michael Mrozek wrote:
That sounds good. notaz might be able to correct me here, but the problem is actually not the closed-source stuff from IMG (like the SGX driver, etc.), but another small binary blob that's used to communicate between X and the SGX driver.
Not X, see below.
There could be other libs that I'm not aware of, but afaik that is the EXA driver. Which is from IMG, and is closed. That driver uses SGX underneath.
It is gbm_pvr.so, which is some weird dependency to mesa. Without it the blobs would not run, and it's tied to ancient mesa from Ubuntu 12.04. There is absolutely no reason to keep this one closed, it's a tiny lib with just some glue code (from looking at the symbols), yet it's enough to make distribution maintainer's life miserable.
The EXA driver is separate from the above and it was possible to get 3D going without it (fullscreen without X support, just drawing over what X draws) by doing some nasty hacks, but I already forgot the details.
Grazvydas
On 10/06/2015 10:56 PM, Grazvydas Ignotas wrote:
Hi,
For the general problem of slow X, we might be able to still use fbturbo on top of omapdrm's fb emulation. That was working at last year's gamescom, on TI's old 3.8 kernel.
I've done a bit of research on using glamor, and there's not a lot of info out there. Apart from a mention of "GLES2 port on PVR545 platform" on the glamor site, there weren't any details on what and how they were using it.
I did find a bit of info on using it on the rpi, where they seem to run it on top of xserver-xorg-video-modesetting (Driver "modesetting" in the xorg.conf), so I decided to give that a try. Glamor doesn't seem to work out of the box with the version in debian, but using the modesetting driver alone turned out to be a lot more usable then the omap one, without massive lag when dragging a window.
I've done a bit of benchmarking using the last few tests of x11perf ( x11perf -comppixwin500 -getimagexy500 -shmgetxy500 -shmputxy500 -putimagexy500 -deepcopyplane500 -copyplane500 -copypixpix500 -scroll500 )
Probably not that useful, but it does give a slightly more objective indication of the speed of the various drivers.
omap/modeset/turbo running on the 4.2 hns drm kernel, turbo4.3 on the normal 4.3-rc4
results are ops/sec 500x500 omap modeset turbo turbo4.3 Scroll 182.0 186.0 4110.0 4190.0 Copy Pixmap 115.0 4670.0 5020.0 4970.0 Copy 1bit 420.0 758.0 768.0 806.0 Copy nbit 30.9 310.0 257.0 260.0 PutImage 1.0 1.0 22.2 22.4 ShmPutImage 1.0 21.6 21.1 20.7 ShmGetImage 1.3 1.3 21.4 21.5 GetImage 1.3 1.3 19.9 20.3 Composite 165.0 1540.0 2060.0 2070.0
On 07/10/15 01:44, aTc wrote:
On 10/06/2015 10:56 PM, Grazvydas Ignotas wrote:
Hi,
For the general problem of slow X, we might be able to still use fbturbo on top of omapdrm's fb emulation. That was working at last year's gamescom, on TI's old 3.8 kernel.
I've done a bit of research on using glamor, and there's not a lot of info out there. Apart from a mention of "GLES2 port on PVR545 platform" on the glamor site, there weren't any details on what and how they were using it.
I did find a bit of info on using it on the rpi, where they seem to run it on top of xserver-xorg-video-modesetting (Driver "modesetting" in the xorg.conf), so I decided to give that a try. Glamor doesn't seem to work out of the box with the version in debian, but using the modesetting driver alone turned out to be a lot more usable then the omap one, without massive lag when dragging a window.
I've done a bit of benchmarking using the last few tests of x11perf ( x11perf -comppixwin500 -getimagexy500 -shmgetxy500 -shmputxy500 -putimagexy500 -deepcopyplane500 -copyplane500 -copypixpix500 -scroll500 )
Probably not that useful, but it does give a slightly more objective indication of the speed of the various drivers.
omap/modeset/turbo running on the 4.2 hns drm kernel, turbo4.3 on the normal 4.3-rc4
results are ops/sec 500x500 omap modeset turbo turbo4.3 Scroll 182.0 186.0 4110.0 4190.0 Copy Pixmap 115.0 4670.0 5020.0 4970.0 Copy 1bit 420.0 758.0 768.0 806.0 Copy nbit 30.9 310.0 257.0 260.0 PutImage 1.0 1.0 22.2 22.4 ShmPutImage 1.0 21.6 21.1 20.7 ShmGetImage 1.3 1.3 21.4 21.5 GetImage 1.3 1.3 19.9 20.3 Composite 165.0 1540.0 2060.0 2070.0
It's interesting that omap and modeset drivers has such different results. Well, the omap driver hasn't really been maintained for a long time, but still. I would presume things like "copy pixmap" is done in the same way with CPU. I think the results point to some kind of bug in the omap driver.
In any case, a generic (maintained) KMS driver sounds much better to me than the omap specific driver. The only additional thing the omap driver really offers is the support for rotation with TILER.
And, well, the omap driver also uses a HW plane for cursor, but that's not working very well. Then again, that's something that a generic KMS driver could also do (but doesn't, with a quick glance). Although with the legacy non-atomic-modesetting API, it will never work very well.
I just compiled modeset driver (0.9.0) for my buildroot setup, and unfortunately it crashes when I start a window manager =(. You didn't see any issues?
fbturbo seems to be fast, but as I said in the other mail, I presume it doesn't support any of the nice features offered by DRM. Someone should write modeset-turbo =). Well, probably only porting the NEON parts would be already enough.
Tomi
On 07/10/15 13:12, Tomi Valkeinen wrote:
In any case, a generic (maintained) KMS driver sounds much better to me than the omap specific driver. The only additional thing the omap driver really offers is the support for rotation with TILER.
And, well, the omap driver also uses a HW plane for cursor, but that's not working very well. Then again, that's something that a generic KMS driver could also do (but doesn't, with a quick glance). Although with the legacy non-atomic-modesetting API, it will never work very well.
Also, there's the xf86-video-armsoc driver. I didn't try it, but I don't know why it's "armsoc", as with a quick look it seems to be a kms modesetting driver, with special bits and pieces for two arm soc buffers. It also has support for dumb buffers, so it might just work on omap also. And implementing omap buffer support should be quite simple (again, with only a quick glance at the sources =).
armsoc driver has seen development recently, while the latest commit in the modesetting driver was a year or so old.
Tomi
On 10/07/2015 12:12 PM, Tomi Valkeinen wrote:
I just compiled modeset driver (0.9.0) for my buildroot setup, and unfortunately it crashes when I start a window manager =(. You didn't see any issues?
I'm using the one included in debian jessie, which usually means some pathches have been applied in various places. The only issue i saw was that initially there's no mousepointer, but it pops up later, probably after the pointer image changed.
On 07/10/15 01:44, aTc wrote:
results are ops/sec 500x500 omap modeset turbo turbo4.3 Scroll 182.0 186.0 4110.0 4190.0 Copy Pixmap 115.0 4670.0 5020.0 4970.0 Copy 1bit 420.0 758.0 768.0 806.0 Copy nbit 30.9 310.0 257.0 260.0 PutImage 1.0 1.0 22.2 22.4 ShmPutImage 1.0 21.6 21.1 20.7 ShmGetImage 1.3 1.3 21.4 21.5 GetImage 1.3 1.3 19.9 20.3 Composite 165.0 1540.0 2060.0 2070.0
Btw, I did some quick tests on my buildroot setup, after finally finding out why many xdrivers crash for me (-Os crashes, -O3 works). I also had a short discussion with Rob Clark some time ago, who says:
-omap uses GEM buffers, which iirc are all mapped writecombined (so CPU read will be *slow*) so that it can support dri2/gpu.. I think -modeset probably only uses a GEM buffer for scanout and malloc buffers for everything else when you don't have glamor enabled (which also would mean no dri2 in that config).
It is odd that PutImage would be so much slower, I wouldn't have expected that much penalty to wc buffers for only write access (although that could be something that differs between a8/a9/a15..)
Simple window dragging test shows that omap driver is quite slow. But modesetting driver works nicely for me, and supports KMS. I did a quick run on DRA7 with the x11perf:
( 2950.0/sec): Scroll 500x500 pixels ( 3340.0/sec): Copy 500x500 from pixmap to pixmap ( 712.0/sec): Copy 500x500 1-bit deep plane ( 281.0/sec): Copy 500x500 n-bit deep plane ( 14.3/sec): PutImage XY 500x500 square ( 13.0/sec): ShmPutImage XY 500x500 square ( 25.8/sec): ShmGetImage XY 500x500 square ( 19.2/sec): GetImage XY 500x500 square ( 1870.0/sec): Composite 500x500 from pixmap to window
So, no expert here, but I think the omap driver should only be used if SGX accel is there. With plain CPU support, modesetting seems to work fine.
Tomi
Am Fri, 15 Jan 2016 15:18:26 +0200 hat Tomi Valkeinen tomi.valkeinen@ti.com geschrieben:
Hi Tomi,
thanks for the info! It would be okay for us to use the SGX only for OpenGL ES programs and games in fullscreen mode.
The question is: Can X run in modeset (or turbo4.3) and the SGX can be used for OpenGL ES in fullscreen on top of it?
While we don't really need the SGX for the desktop usage, it should still be available and work for games that are being run from the desktop.
On 07/10/15 01:44, aTc wrote:
results are ops/sec 500x500 omap modeset turbo turbo4.3 Scroll 182.0 186.0 4110.0 4190.0 Copy Pixmap 115.0 4670.0 5020.0 4970.0 Copy 1bit 420.0 758.0 768.0 806.0 Copy nbit 30.9 310.0 257.0 260.0 PutImage 1.0 1.0 22.2 22.4 ShmPutImage 1.0 21.6 21.1 20.7 ShmGetImage 1.3 1.3 21.4 21.5 GetImage 1.3 1.3 19.9 20.3 Composite 165.0 1540.0 2060.0 2070.0
Btw, I did some quick tests on my buildroot setup, after finally finding out why many xdrivers crash for me (-Os crashes, -O3 works). I also had a short discussion with Rob Clark some time ago, who says:
-omap uses GEM buffers, which iirc are all mapped writecombined (so CPU read will be *slow*) so that it can support dri2/gpu.. I think -modeset probably only uses a GEM buffer for scanout and malloc buffers for everything else when you don't have glamor enabled (which also would mean no dri2 in that config).
It is odd that PutImage would be so much slower, I wouldn't have expected that much penalty to wc buffers for only write access (although that could be something that differs between a8/a9/a15..)
Simple window dragging test shows that omap driver is quite slow. But modesetting driver works nicely for me, and supports KMS. I did a quick run on DRA7 with the x11perf:
( 2950.0/sec): Scroll 500x500 pixels ( 3340.0/sec): Copy 500x500 from pixmap to pixmap ( 712.0/sec): Copy 500x500 1-bit deep plane ( 281.0/sec): Copy 500x500 n-bit deep plane ( 14.3/sec): PutImage XY 500x500 square ( 13.0/sec): ShmPutImage XY 500x500 square ( 25.8/sec): ShmGetImage XY 500x500 square ( 19.2/sec): GetImage XY 500x500 square ( 1870.0/sec): Composite 500x500 from pixmap to window
So, no expert here, but I think the omap driver should only be used if SGX accel is there. With plain CPU support, modesetting seems to work fine.
Tomi
On 15/01/16 15:27, Michael Mrozek wrote:
It would be okay for us to use the SGX only for OpenGL ES programs and games in fullscreen mode.
The question is: Can X run in modeset (or turbo4.3) and the SGX can be used for OpenGL ES in fullscreen on top of it?
While we don't really need the SGX for the desktop usage, it should still be available and work for games that are being run from the desktop.
I don't know...
I do know SGX can be run without windowing system, directly on top of DRM. So maybe it's possible to exit X or switch the virtual terminal, and then run the app on top of DRM.
But if the app runs on X, then I guess the SGX must be fully supported by the X.
But really, this is outside my experience...
Tomi
On 06/10/15 23:56, Grazvydas Ignotas wrote:
Hi,
For the general problem of slow X, we might be able to still use fbturbo on top of omapdrm's fb emulation. That was working at last year's gamescom, on TI's old 3.8 kernel.
Hmm interesting. So fbturbo is an X fbdev driver, with (for this case) NEON optimized operations? I presume none of the HW accelerations included can be used with OMAP?
One issue with fbdev driver, and probably with fbturbo also, is that it's using the fbdev. So it has no understanding of multiple displays, videomodes, etc, etc.
On 10/06/2015 02:23 PM, Tomi Valkeinen wrote:
On 06/10/15 14:18, Michael Mrozek wrote:
That sounds good. notaz might be able to correct me here, but the problem is actually not the closed-source stuff from IMG (like the SGX driver, etc.), but another small binary blob that's used to communicate between X and the SGX driver.
Not X, see below.
There could be other libs that I'm not aware of, but afaik that is the EXA driver. Which is from IMG, and is closed. That driver uses SGX underneath.
It is gbm_pvr.so, which is some weird dependency to mesa. Without it the blobs would not run, and it's tied to ancient mesa from Ubuntu 12.04.
GBM is a buffer allocation library from Mesa. gbm_pvr has the glue between mesa-omapdrm-sgx. It allows opengl to allocate buffers which can be drawn by the SGX and shown on the screen.
There is absolutely no reason to keep this one closed, it's a tiny lib
The reason is IMG =). It's difficult to open source anything related to SGX, as using SGX driver's internal headers makes it impossible to open source it.
If I'm not mistaken, the only public headers from SGX are related to opengl and egl. Any component using any other APIs must be closed source.
with just some glue code (from looking at the symbols), yet it's enough to make distribution maintainer's life miserable.
The EXA driver is separate from the above and it was possible to get 3D going without it (fullscreen without X support, just drawing over what X draws) by doing some nasty hacks, but I already forgot the details.
True, there are many different parts in play.
Tomi
Am 02.10.2015 um 13:33 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 02/10/15 14:28, H. Nikolaus Schaller wrote:
I have not checked if it shows output signals but it also says that there are no modes (I had expected at least PAL and NTSC):
xrandr: Output None-2 is not disconnected but has no modes
But if there is no detection, is it possible to turn it completely off (our device shares the TVout with the headset microphone input so that we need some control to switch between both)?
Would xrandr --output None-2 --off turn off VENC?
root@letux:~# xrandr --output None-2 --off xrandr: Output None-2 is not disconnected but has no modes root@letux:~# xrandr --output None-2 --auto xrandr: Output None-2 is not disconnected but has no modes xrandr: cannot find preferred mode root@letux:~#
Ok. Perhaps it's broken. I'm quite sure VENC worked at some point. My beagle-xm has died some time ago, and they are not sold anymore. That was my only VENC device... =(
I have revitalized my BB-XM (with external LCD) and there I have the same:
root@gta04:~# xrandr --verbose xrandr: Output None-1 is not disconnected but has no modes Screen 0: minimum 320 x 200, current 480 x 640, maximum 2048 x 2048 None-1 unknown connection (normal) Identifier: 0x41 Timestamp: 37020 Subpixel: unknown Clones: CRTCs: 0 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: None-2 connected 480x640+0+0 (0x43) normal (normal) 0mm x 0mm Identifier: 0x42 Timestamp: 37020 Subpixel: unknown Gamma: 1.0:1.0:1.0 Brightness: 1.0 Clones: CRTC: 1 CRTCs: 1 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: 480x640 (0x43) 22.153MHz -HSync -VSync *current +preferred h: width 480 start 504 end 512 total 520 skew 0 clock 42.60KHz v: height 640 start 644 end 646 total 648 clock 65.74Hz root@gta04:~#
What I have not tried is mainline for beagleboard. So I can't 100% exclude that we have something in our Letux kernel additions that creates this effect.
For cross-checks on Pandaboard and BeagleBoneBlack I have to update the µSD cards first to Jessie.
On 03/10/15 20:35, H. Nikolaus Schaller wrote:
Ok. Perhaps it's broken. I'm quite sure VENC worked at some point. My beagle-xm has died some time ago, and they are not sold anymore. That was my only VENC device... =(
I have revitalized my BB-XM (with external LCD) and there I have the same:
root@gta04:~# xrandr --verbose xrandr: Output None-1 is not disconnected but has no modes Screen 0: minimum 320 x 200, current 480 x 640, maximum 2048 x 2048 None-1 unknown connection (normal)
I made a quick test with HDMI, and made the HDMI connector return uknown connection. One thing I noticed that an "unknown connection" connector needs to be enabled explicitly (which makes sense). Doing this enabled it for me:
xrandr --output HDMI-1 --auto
However, I was seeing a single 640x480 mode even before that, and you don't. I don't have any idea about that. You may want to add some debug prints to connector-analog-tv.c's get/set/check_timing functions. And to omap_connector.c's omap_connector_get_modes().
Tomi