Hello,
I've got a couple of questions about the fbcon implementation in detail, in
order to cleanup my code and create a mergable patch for review.
For the graphic text output, I've implemented two functions _RPI_initvideo and
_RPI_outch, used to print chars to graphic. They are declared in bsp.h and
implemented in outch.c as we've done in i386 bsp.
1. The _RPI_initvideo function need to initialize framebuffer driver and get
the informations. I think it would not be logical nor safe if I don't declare
the fb_init function as static and call it from outside. If I just wait for
the initialization of fb driver, and expose getters for the fb infos, it works
but we will miss all output before the fb initialized. Another proposition, we
would always let the driver itself to decide the resolution and it won't change
after the first init. Then the fb_init function can be exposed to others (just
return if it's called a second time) and it can be called at the bsp startup or
somewhere else.
I haven't yet come up with a better idea. It would be great if anyone has any
better solutions.
2. The mmu configuration for framebuffer. I'm still confused about how to deal
with it.
Is there anyway to setup the memory in the code ? For exemple: after
detected the size and start point of framebuffer, setup a given block (range)
to ARMV7_MMU_DATA_READ_WRITE in the code?
I prefer to setup the mmu table after the fb initialized. If it's not possible, like we've discussed earlier, we should enable all possible area at startup. Since the start point varies for different devices, how can I find out the pages to be activate?
3. Not like in i386, I've got to take a ascii font file for drawing characters.
I've taken the hard cored 8*16 font from UBOOT code. I think maybe we can move
the font file in a common directory for all bsps. It's not so important, just a
suggestion. Also the EDID header may be moved for all bsps as well.
On May 04, 2015, at 12:08 PM, QIAO YANG <yangqiao0...@me.com> wrote:
Hello everyone,
Since I haven't yet received any respond of my last mail and I've now got the
names of mentors who would instruct me, I create a new thread for a simple
resume and post my questions .
First of all, I've managed to use mailbox channel to get a framebuffer pointer
and its informations. I can draw some simple images with the pointer and also
the pointer can be retrieved correctly by ioctrl from applications, with the fb
device interface. Painting works as well.
I've already sent a patch with mailbox implementation, but I haven't yet
confirmed if it's ready to be merged or any modification should be done.
To complete fb implementation:
1. Some more functions need to be added : connected monitor EDID read and
decoding for correct/optimal resolution selection. I don't know if we need a
full VESA driver like what we've done on i386.
2. If we've enabled l2 cache, the memory mapping would be 0x40000000, while
the mapping would be 0xC0000000 instead if l2 cache disabled. Normally it can
be configured in the config.txt file.
The file 'config.txt' is read by GPU before the ARM core is initialized. It's
used as an BIOS configuration. It can be used to setup hdmi output mode, l2
cache, memory split etc. Such as memory split affect much the range of
framebuffer address which should be covered in the mmu configuration table.
What would be a better way to deal with it? Should I enable the memory pages
that cover all possible range(This can vary depend on gpu_mem_split) ?
To plan for fbcon implementation:
1. Find instructions for cursor. I've found that it's possible to get some
infos from mailbox property channel.
2. Implementations refering to i386/pc386/console/outch.c
3. Implementations refering to i386/pc386/console/vgacons
For GTK porting
I tried to compile gtk for it. The libpng ... etc can be installed and I'm
trying to make some samples for testing. Only the nxlib failed to build because
we haven't yet the keyboard support (mouse support can be switched off, but I
can't find out yet how to build the lib without keyboard).
That's all for a resume, plan, and questions report for my work.
Best regards,
YANG Qiao
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
