Re: Fwd: Barebox 2017.02 works great but no Linux Framebuffer... :-/

[gianluca <gianlucarenzi@eurekelettronica.it>]

On 06/21/2017 05:30 PM, Lucas Stach wrote:
> Am Mittwoch, den 21.06.2017, 17:18 +0200 schrieb gianluca:
>> On 06/21/2017 01:50 PM, Lucas Stach wrote:
>>> root@edelin:~# cat /proc/cmdline
>>> console=ttymxc2,115200 rootwait noswap ip=none noinitrd rootfstype=nilfs2 \
>>  > root=/dev/mmcblk1p3 fec.macaddr=0x7a,0x3f,0x03,0xe3,0xa2,0xff \
>>  > system_rev=0xe3600000 system_serialnr=0x00000000 \
>>  > lcd_type=am1280800n3tz fastboot quiet loglevel=3 console=tty0 \
>>  > video=mxcfb0:dev=ldb,if=RGB24,bpp=32 \
>>  > fbmem=32M vmalloc=400M imx-drm.legacyfb_depth=32
>>
>> As you can see imx-drm.legacy_depth=32 is passed to the kernel from
>> bootloader.
>
> The module is called "imxdrm" without a dash, so the correct way to
> specify the parameter on the command line is "imxdrm.legacyfb_depth=32".
>
> I'm not sure what you are trying to achieve with the mxcfb and fbmem
> parameters. They are certainly ignored by a mainline kernel.
>

It works now, the culprit was the name of the driver: imxdrm is the 
right one.


Now a little bit off-topic question:

- Is it better to use Xorg X11 (with a custom full screen application 
using Qt 5) [with all concerns about using a Debian Jessie for armhf, 
i.e.: imx-drm-vivante driver, opengl/opencl custom libraries etc.,...] 
or using a framebuffer Qt application??? I know the framebuffer does not 
have any acceleration, but I suppose the CPU (even the dual-core) is 
powerful enough to manage some simple transition of the application pages...

What do you think about this?

Regards,
-- 
Eurek s.r.l.                          |
Electronic Engineering                | http://www.eurek.it
via Celletta 8/B, 40026 Imola, Italy  | Phone: +39-(0)542-609120
p.iva 00690621206 - c.f. 04020030377  | Fax:   +39-(0)542-609212

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox