Hello sirs,
I've cleaned up my works for fb implementation and the graphic console. Now it's available on my github: mailbox: https://github.com/yangqiao/rtems/commit/4b4239135d23d82c2a284c8c848d8f97cd3c5e41 videocore: https://github.com/yangqiao/rtems/commit/38c26a49126e5cff92ae389dba252cb180362c90 fb : https://github.com/yangqiao/rtems/commit/979a15412f84f8b0095a613d66cddbc3ca777efc outch: https://github.com/yangqiao/rtems/commit/858a9b091025acc4bfe912f41d70c9a73b99d773 fbcons: https://github.com/yangqiao/rtems/commit/1d82ef8ff28e0ef6a062313ca4874fe720a32e6e A screen shot for the graphic text console is in attachment. Still some problem I've got difficulties to solve : 1. Will rpi bsp has any kernel command line setup like i386? This would let us to choose fb console port or serial console port . Or maybe we just use compiler macro to enable/disable graphic console output? 2. I've found that printk don't output to serial port instead of fbcons even if I've set up the BSPPrintkPort to the fb console. Is it acceptable or what I missed in the console implementation? I've read through the i386 bsp but I can't find out the reason. 3. I still have no idea on how can I find out all possible fb buffer's location as we need to enable the segment of memory in mmu configuration. I can find few document on how the cpu allocate the buffer. I'm trying to ask other communities, forums. Something waiting to be done: 1. graphic console need the keyboard implementation . I would like to know the status of keyboard implementation. 2. generate a bitmap font file instead of the one I used under GPL. 3. restructure the reusable code after the it's reviewed. I will post a blog later for my works. I'll leave the commits for you to review. On Jun 07, 2015, at 10:53 PM, QIAO YANG <yangqiao0...@me.com> wrote: Hi, I've got a few questions over the fbcons implementation details and edid lecture: 1. I should place the video init function where exactly? In the end of bspstarthooks.c hook_1() or in the bspstart.c ? 2. I need to ensure the structure buffer is 16-byte aligned . I use __attribute__((aligned (16))) to specific the alignement. Is there any rtems macro for this or it's ok that I use the compiler attribute for all structure definition? 3. Is it necessary to encapsule the communication with videocore interfaces with individual functions? Or just let the developper construct the buffer to send in a certain structure with the macros defined? 4. I've read many others' implementations of framebuffer. I've found that they all just query the display size by the videocore interface and use that for the resolution setup. So I wonder if it's obliged to get the EDID blocks, parse it then decide the resolution. I proposed that we try to get the resolution from cmdline setup, use it if it's supported. If the setup is not supported, we'll query the display size. Normally the query can't fail as all others will throw an error when the query failed and stop the fbinit in their code (except for qemu emulator, width=0,height= 0 will be returned) . If the query does fail, we will then try the default resolution: 640*480. For now, I think I've just need some more time to cleanup, write test samples and then send patches. If everything's ok next week I'll move to test and adapt the graphic libraries.
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
