BBB Framebuffer driver : Project status

[Christian Mauderer]

On 25/06/2019 19:42, Gedare Bloom wrote:
> On Tue, Jun 25, 2019 at 10:36 AM Vijay Kumar Banerjee
> <vijaykumar9597 at gmail.com> wrote:
>>
>>
>>
>> On Tue, Jun 25, 2019 at 9:32 PM Gedare Bloom <gedare at rtems.org> wrote:
>>>
>>> On Tue, Jun 25, 2019 at 5:34 AM Vijay Kumar Banerjee
>>> <vijaykumar9597 at gmail.com> wrote:
>>>>
>>>> Hello,
>>>>
>>>> The First Evaluation is going on and I here I would summarize all the progress
>>>> that the project has made in the first Phase.
>>>>
>>>> 1. The major progress is the completion of the I2C adaptation layer in the libbsd
>>>>      along with the iicbus driver imports. The v4 of the driver [1] has been tested to be
>>>>      working with the bbb-i2c driver patch [2]. After the RTEMS driver is updated in the
>>>>      master, the adaptation layer will be mergeable.
>>>>
>>>> 2. I am getting EDID reading from the imported tda drivers. I have checked this using
>>>>     the ti_i2c driver but now as we have an updated version  of the driver, I'll pull this all
>>>>     with the adaptation layer and will continue from there.
>>>>
>>>> 3. I found a sample app from the freebsd mailing list, that draws a basic shape on the
>>>>     screen. I have made it a standalone app with only single source and have tested it
>>>>      to be working with the FreeBSD. The only issue with the code is that it uses mmap
>>>>      and RTEMS doesn't use mmap so I'm rewriting the app with pread and pwrtie on
>>>>      to write to the /dev/fb0 directly. This app work is ongoing.
>>>>
>>> We have a rudimentary mmap() support available. I would expect this
>>> might be important to investigate for graphics applications in general
>>> might be trying to mmap() device memory.
>>>
>> At this moment, my objective is to just test that the fb device is working.
>> For that, as I said, I'm trying to rewrite the mmap with pread instead. So
>> far I couldn't get anything on screen with it though but if the writes work
>> then I'm expecting to see something on the screen.
>> As you have pointed out that most graphics applications will be using
>> mmap(). Do you suggest trying to improve mmap() support as a part
>> of this project? Is that expected to take a lot of time?
>>
> 
> I leave this decision up to you and your mentors whether (and why) to
> re-prioritize any of your work.
> 

Vijay: If you are interested you can of course start to have a look at
the mmap support right now. Just now that would be more a general
improved mmap support (for any kind of file) which certainly would be a
benefit for RTEMS too. But it would mean that you more or less stop with
the frame buffer. I don't have a problem with it if you want to do that
but I wouldn't suggest it.

My suggestion would be to first continue with the frame buffer till the
test application works. You already did quite a bit into that direction
and it would be a pity if it couldn't be merged. If that is done you
have reached a quite nice mile stone. So from there there would be two
possible further directions:

a) Either you can continue with the original plan to add a console (from
RTEMS or from FreeBSD) and then - depending on time - some demo
applications.

b) Or after the framebuffer works you take a look how mmap support could
look for _some_ special devices. That would make it simpler to port new
graphics libraries to RTEMS (like QT - we could just use the bsdfb
driver) which would be a really nice thing too. Maybe that would be even
more useful then a simple console. Most embedded systems will use a
serial port for the system console and will use a displays to show a GUI
for a user.

Like I said: You can decide which way you want and I'll support every
decision. But the most useful one - and therefore the one I would
suggest - would be the solution b).

Oh and while writing that I noted: I'm not even sure whether libbsd
device drivers fall back to the same rudimentary mmap that is used for
file systems in RTEMS like I thought. Maybe you are even able to use the
mmap support right now. Might could be a good idea to just try a mmap
call in a simple test application (without any reading or writing to it)
and try with a debugger whether you reach some driver function.

Best regards

Christian

> 
>>>> Next Up:
>>>> 1. merge the ported TDA driver and using it with the adaptation layer.
>>>> 2. Import and port the fbd dirver to create an fb0 device.
>>>> 3. complete the sample app and convert it into a libbsd sample app to test the device.
>>>>
>>>> Thanks,
>>>> Vijay
>>>>
>>>> _______________________________________________
>>>> devel mailing list
>>>> devel at rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/devel