[PATCH 1/2] i386/pc386/VESA framebuffer driver: modified and extended initialization options

[Gedare Bloom]

On Tue, May 19, 2015 at 1:19 PM, Gedare Bloom <gedare at rtems.org> wrote:
> On Tue, May 19, 2015 at 1:09 PM, Jan Dolezal <dolezj21 at fel.cvut.cz> wrote:
>> Hello Gedare,
>> thank you for the swift response..
>>
>>
>> On 19.5.2015 17:38, Gedare Bloom wrote:
>>>
>>> On Tue, May 19, 2015 at 10:34 AM, Jan Dolezal <dolezj21 at fel.cvut.cz>
>>> wrote:
>>>>
>>>> driver is not initialized by default
>>>> initialization is possible through multiboot command line option or
>>>> through string variable set in user's module allowing the driver
>>>> to evaluate this variable after the two modules are linked together
>>>> ---
>>>>   c/src/lib/libbsp/i386/pc386/console/fb_vesa_rm.c | 152
>>>> +++++++++++++++++++----
>>>>   1 file changed, 127 insertions(+), 25 deletions(-)
>>>>
>>>> diff --git a/c/src/lib/libbsp/i386/pc386/console/fb_vesa_rm.c
>>>> b/c/src/lib/libbsp/i386/pc386/console/fb_vesa_rm.c
>>>> index d6fd174..5c4d8bf 100644
>>>> --- a/c/src/lib/libbsp/i386/pc386/console/fb_vesa_rm.c
>>>> +++ b/c/src/lib/libbsp/i386/pc386/console/fb_vesa_rm.c
>>>> @@ -19,8 +19,14 @@
>>>>    *
>>>>    * Driver reads parameter from multiboot command line to setup video:
>>>>    * "--video=<resX>x<resY>[-<bpp>]"
>>>> - * If cmdline parameter is not specified an attempt for obtaining
>>>> - * resolution from display attached is made.
>>>> + * "--video=auto" - try EDID to find mode that fits the display attached
>>>> best
>>>> + * "--video=none" / "--video=off" - do not initialize the driver
>>>> + * If cmdline parameter is not specified the rtems_console_vbe_default
>>>> + * variable content is tested (see doc below).
>>>> + * Command line option has higher priority. rtems_console_vbe_default is
>>>> probed
>>>> + * only if cmdline "--video=" is not specified at all.
>>>> + *
>>>> + * If neither of the above options is specified the driver is not
>>>> initialized.
>>>>    */
>>>>
>>>>   /*
>>>> @@ -31,7 +37,7 @@
>>>>    * found in the file LICENSE in this distribution or at
>>>>    * http://www.rtems.org/license/LICENSE.
>>>>    *
>>>> - * The code for rtems_buffer_* functions were greatly
>>>> + * The code for rtems_buffer_* functions was greatly
>>>>    * inspired or coppied from:
>>>>    *   - RTEMS fb_cirrus.c - Alexandru-Sever Horin
>>>> (alex.sever.h at gmail.com)
>>>>    */
>>>> @@ -53,6 +59,22 @@
>>>>   #define FB_VESA_NAME    "FB_VESA_RM"
>>>>
>>>>   /**
>>>> + * @brief Allows to enable initialization of this driver from an
>>>> application
>>>> + * by setting the value of this variable to non null value in
>>>> + * user's module. The value of this variable will be then updated
>>>> + * when linked with application's object.
>>>> + *
>>>> + * Further if the value points to string in format:
>>>> + * "<resX>x<resY>[-<bpp>]"
>>>> + * "auto" - try EDID to find mode that fits the display attached best
>>>> + * "none" / "off" - do not initialize the driver
>>>> + * the given parameters are used if applicable.
>>>> + *
>>>> + * Command line option string has priority over this string.
>>>> + */
>>>> +const char * const rtems_console_vbe_default;
>>>> +
>>>
>>> If this variable is not exported elsewhere, it should be made 'static'.
>>
>>
>> The point is to make this variable available for exporting somewhere
>> else, specifically the application that wishes to use the driver, sets
>> this variable to the string containing the resolution requested to be
>> set. When the application is linked together with this module,
>> rtems_console_vbe_default points to that string and the driver can
>> initialize itself using the string from the application.
>>
> Then should this variable be declared in a header visible to both the
> user application and this source code file as extern?
>
Resolve this issue and we can probably commit.