On Sun, Jun 14, 2015 at 6:31 AM, QIAO YANG <yangqiao0...@me.com> wrote:
> > 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 > > I'll try to take a look at these. > 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? > > I don't know the answer here. I suspect it would be easiest to use a BSPOPT feature to get started. > 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. > > I'm confused, do you mean printk always goes to the serial port? That's probably OK. > 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. > > Ok. One approach is to just run it and see what addresses it accesses. I would have guessed either there is a specific memory region that is well-known, or that there is a way to set the memory region yourself through some mailbox. > Something waiting to be done: > > 1. graphic console need the keyboard implementation . I would like to know > the status of keyboard implementation. > > If you can use an SPI keyboard, I think this can be done easily/quickly. USB keyboard probably won't be possible yet. > 2. generate a bitmap font file instead of the one I used under GPL. > > 3. restructure the reusable code after the it's reviewed. > > OK. > 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 >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
