#cubox irc log of Wed 19 Apr 2017

IRC log of #cubox of Wed 19 Apr 2017. All times are in CEST < Back to index

07:49 inch I tried kmscube with a "HP w19b" and got the same error which I had with BK101TH-L400-GH513A. It still works with Philips 272C4.

08:03 inch Now I have Qt 5.8 compiled for Debian stretch armhf against the libdrm and mesa from git (etnaviv,imx). Qmlscene starts and shows the file dialog even with the HP.

09:23 topi` did you check that Qmlscene is actually using the hardware drm driver? and not llvmpipe

09:23 topi` there is usually a warning about "using llvmpipe, expect reduced performance"

09:32 inch https://k2c42.dy.fi/etnaviv/qmlscene1.txt

09:34 inch The BK101TH-L400-GH513A works with qmlscene when I set resolution to 1024 x 768

10:55 topi` what does qmlscene do? some 2d or 3d rendering?

10:57 topi` inch: I would set this to "false":

10:57 topi` pbuffers: true

10:58 topi` the docs say this about setting pbuffers to true:

10:58 topi` it will back QOffscreenSurface with standard EGL pbuffer surfaces (by default this is disabled and a gbm surface is used instead),

10:58 topi` I guess a GBM surface should be used? at least it is closer to hardware

11:01 topi` inch: one thing to check if DRM rendering starts to fail... check the amount of CMA allocation for the drm

11:01 topi` dmesg | grep -i cma

11:02 topi` I have it now at 256MB, but when I had only 16MB, almost nothing worked, only kmscube (it needs very little)

11:02 topi` if you know raspberrypi, this is exactly the same thing: the GPU/disp side needs some contiguous memory set aside

11:02 inch qmlscene runs qml apps. Qt will use whatever acceleration it can.

11:03 inch I got the pbuffers setting from some Qt example. I'll try turning it off.

11:04 inch Yeah, the gpu memory thing crossed my mind, but I forgot it when I started to get some stuff working.

11:05 inch "cma: Reserved 64 MiB at 0x4c000000". I think there should be more. Where do I change it?

11:06 topi` kernel parameter cma=xxx

11:07 topi` I have cma=256M which seems to be adequate ;)

11:07 topi` AFAIK the unused CMA areas can still be allocated for other kernel purposes like filesystem buffers

11:08 topi` so it doesn't "go to waste"

11:09 inch I think this is actually going to work. I got the "minimal" webengine example to work with a website that does fading on a text and it works ok.

11:10 topi` sounds like the etnaviv works "just enough", even though it is experimental in nature

11:10 topi` I like the fact that it is completely open source, unlike most other 3D drivers

11:11 topi` upgrading kernels, etc, is a bit less stressful :)

11:11 topi` some time ago, we had to upgrade the stock kernel to something that would work properly with a piece of USB hardware, but getting the ATI fglrx stuff working with that kernel was a pain

11:12 topi` a royal pain

11:12 topi` *shudder*

11:12 topi` I think the opensource radeon drivers have progressed by now

11:13 inch Etnaviv has a potential to become the thing that "just works".

11:13 inch A competitor for raspberry pi which also "just work".

11:15 topi` I wouldn't compare rpi to the Hummingboard series... the latter is much higher quality

11:16 topi` the rpi will die if its USB buses are pushed hard since everything shares a single USB controller

11:16 topi` the HB will offer full USB2 bandwidth on both its connectors

11:17 topi` if versatility counts, the HB wins hands down :) of course it is more $$$ as well

11:33 inch I've been playing with sheevaplug, trimslice, igep2, raspberry pi, banana pi, utilite2 and now hummingboard. Sheevaplug doesn't count (no gpu) but from all the others, only raspberry pi has "just worked".

11:35 vpeter Then we can conclude rpi has the best support :)

11:35 vpeter Which is not far from truth.

11:43 inch Sheevaplug was/is great, because I could just install Debian and use it. If I some day need to replace it I'd want another small single board computer where I can just install Debian. Raspberry is not an option in this case because it has slow ethernet connection.

11:43 topi` community work can change all this. Witness the nonexisting software support for Orange PI boards, and then the armbian guys came and made it a relevant platform

11:49 vpeter The point is 'can'. If platform is not widely interested then even community will not do to make it better. Or even usable.

12:00 topi` bottom line is, raspberry pi is crappy, especially if you want to build anything that requires plenty of USB2 bandwidth. Even the cheapest Orange PI PC 2 beats the crap out of it when looking at usable bandwidth

12:09 vpeter But obviously in this case you would not look for rpi.

12:11 inch Here are some notes about this libdrm+mesa+qt-compilation: https://k2c42.dy.fi/etnaviv/qt5/compile.txt

12:11 inch And patches and "distcc-wrap" there: https://k2c42.dy.fi/etnaviv/qt5/

13:24 topi` so parallel compilation won't work with crosscompiling qt5?

13:26 topi` about the patch that changes /usr/lib/libXXX.so to /usr/lib/arm-linux-gnueabihf/libXXX.so ... shouldn't a simple call to "ldconfig" take care of that? if the Debian multiarch support is enabled, ldconfig should pick up libs from that arch-specific path

13:27 topi` I think /usr/lib should only contain ld-linux-xxx.so on multiarch systems, and nothing more

14:24 inch That no-multiprocessing patch is rather old. Some time in the past gyp multiprocessing didn't work without proc mounted in chroot so I just turned it off.

14:24 inch And didn't bother to try if it works now.

14:28 inch There seems to be /usr/lib/ hard coded in Qt in so many places that even with the patch I need to symlink the egl libs to /usr/lib.

15:32 inch Do I need to use initramfs to get coda firmware loaded? Now that I Kernel first complains that it can't load vpu_fw_imx6q.bin and then 0.2 seconds later it finds mmcblk2 and mounts the root filesystem.

15:33 inch .. I don't seem to have initrd in use ...

21:55 topi` yes, that seems to indicate the coda fw has to go into the initrd

21:56 topi` I'm not sure if the uboot autoloads initrd, maybe you have to try manual booting...

07:49	inch	I tried kmscube with a "HP w19b" and got the same error which I had with BK101TH-L400-GH513A. It still works with Philips 272C4.
08:03	inch	Now I have Qt 5.8 compiled for Debian stretch armhf against the libdrm and mesa from git (etnaviv,imx). Qmlscene starts and shows the file dialog even with the HP.
09:23	topi`	did you check that Qmlscene is actually using the hardware drm driver? and not llvmpipe
09:23	topi`	there is usually a warning about "using llvmpipe, expect reduced performance"
09:32	inch	https://k2c42.dy.fi/etnaviv/qmlscene1.txt
09:34	inch	The BK101TH-L400-GH513A works with qmlscene when I set resolution to 1024 x 768
10:55	topi`	what does qmlscene do? some 2d or 3d rendering?
10:57	topi`	inch: I would set this to "false":
10:57	topi`	pbuffers: true
10:58	topi`	the docs say this about setting pbuffers to true:
10:58	topi`	it will back QOffscreenSurface with standard EGL pbuffer surfaces (by default this is disabled and a gbm surface is used instead),
10:58	topi`	I guess a GBM surface should be used? at least it is closer to hardware
11:01	topi`	inch: one thing to check if DRM rendering starts to fail... check the amount of CMA allocation for the drm
11:01	topi`	dmesg \| grep -i cma
11:02	topi`	I have it now at 256MB, but when I had only 16MB, almost nothing worked, only kmscube (it needs very little)
11:02	topi`	if you know raspberrypi, this is exactly the same thing: the GPU/disp side needs some contiguous memory set aside
11:02	inch	qmlscene runs qml apps. Qt will use whatever acceleration it can.
11:03	inch	I got the pbuffers setting from some Qt example. I'll try turning it off.
11:04	inch	Yeah, the gpu memory thing crossed my mind, but I forgot it when I started to get some stuff working.
11:05	inch	"cma: Reserved 64 MiB at 0x4c000000". I think there should be more. Where do I change it?
11:06	topi`	kernel parameter cma=xxx
11:07	topi`	I have cma=256M which seems to be adequate ;)
11:07	topi`	AFAIK the unused CMA areas can still be allocated for other kernel purposes like filesystem buffers
11:08	topi`	so it doesn't "go to waste"
11:09	inch	I think this is actually going to work. I got the "minimal" webengine example to work with a website that does fading on a text and it works ok.
11:10	topi`	sounds like the etnaviv works "just enough", even though it is experimental in nature
11:10	topi`	I like the fact that it is completely open source, unlike most other 3D drivers
11:11	topi`	upgrading kernels, etc, is a bit less stressful :)
11:11	topi`	some time ago, we had to upgrade the stock kernel to something that would work properly with a piece of USB hardware, but getting the ATI fglrx stuff working with that kernel was a pain
11:12	topi`	a royal pain
11:12	topi`	shudder
11:12	topi`	I think the opensource radeon drivers have progressed by now
11:13	inch	Etnaviv has a potential to become the thing that "just works".
11:13	inch	A competitor for raspberry pi which also "just work".
11:15	topi`	I wouldn't compare rpi to the Hummingboard series... the latter is much higher quality
11:16	topi`	the rpi will die if its USB buses are pushed hard since everything shares a single USB controller
11:16	topi`	the HB will offer full USB2 bandwidth on both its connectors
11:17	topi`	if versatility counts, the HB wins hands down :) of course it is more $$$ as well
11:33	inch	I've been playing with sheevaplug, trimslice, igep2, raspberry pi, banana pi, utilite2 and now hummingboard. Sheevaplug doesn't count (no gpu) but from all the others, only raspberry pi has "just worked".
11:35	vpeter	Then we can conclude rpi has the best support :)
11:35	vpeter	Which is not far from truth.
11:43	inch	Sheevaplug was/is great, because I could just install Debian and use it. If I some day need to replace it I'd want another small single board computer where I can just install Debian. Raspberry is not an option in this case because it has slow ethernet connection.
11:43	topi`	community work can change all this. Witness the nonexisting software support for Orange PI boards, and then the armbian guys came and made it a relevant platform
11:49	vpeter	The point is 'can'. If platform is not widely interested then even community will not do to make it better. Or even usable.
12:00	topi`	bottom line is, raspberry pi is crappy, especially if you want to build anything that requires plenty of USB2 bandwidth. Even the cheapest Orange PI PC 2 beats the crap out of it when looking at usable bandwidth
12:09	vpeter	But obviously in this case you would not look for rpi.
12:11	inch	Here are some notes about this libdrm+mesa+qt-compilation: https://k2c42.dy.fi/etnaviv/qt5/compile.txt
12:11	inch	And patches and "distcc-wrap" there: https://k2c42.dy.fi/etnaviv/qt5/
13:24	topi`	so parallel compilation won't work with crosscompiling qt5?
13:26	topi`	about the patch that changes /usr/lib/libXXX.so to /usr/lib/arm-linux-gnueabihf/libXXX.so ... shouldn't a simple call to "ldconfig" take care of that? if the Debian multiarch support is enabled, ldconfig should pick up libs from that arch-specific path
13:27	topi`	I think /usr/lib should only contain ld-linux-xxx.so on multiarch systems, and nothing more
14:24	inch	That no-multiprocessing patch is rather old. Some time in the past gyp multiprocessing didn't work without proc mounted in chroot so I just turned it off.
14:24	inch	And didn't bother to try if it works now.
14:28	inch	There seems to be /usr/lib/ hard coded in Qt in so many places that even with the patch I need to symlink the egl libs to /usr/lib.
15:32	inch	Do I need to use initramfs to get coda firmware loaded? Now that I Kernel first complains that it can't load vpu_fw_imx6q.bin and then 0.2 seconds later it finds mmcblk2 and mounts the root filesystem.
15:33	inch	.. I don't seem to have initrd in use ...
21:55	topi`	yes, that seems to indicate the coda fw has to go into the initrd
21:56	topi`	I'm not sure if the uboot autoloads initrd, maybe you have to try manual booting...