From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: plagnioj@jcrosoft.com, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fbmem: really support wildcard video=options for all fbdev drivers
Date: Wed, 08 Jan 2014 13:55:20 +0000 [thread overview]
Message-ID: <52CD58C8.3040703@ti.com> (raw)
In-Reply-To: <1387140035-12234-1-git-send-email-olaf@aepfle.de>
[-- Attachment #1: Type: text/plain, Size: 2043 bytes --]
On 2013-12-15 22:40, Olaf Hering wrote:
> Documentation/fb/modedb.txt states that video=option should be
> considered a global option. But video_setup and fb_get_options are not
> coded that way. Instead its required to boot with video=driver:option to
> set a given option in drvier. This is cumbersome because it requires to
> know in advance which driver will be active for a given board/kernel.
>
> The following patch implements the documented catchall for the fbdev
> drivers. It is now possible to boot with video=XxY without the need to
> know the active driver in advance. The specific case it tries to fix is
> syslinux in the SUSE installer which offers a menu to set a display
> resolution. Right now this just appends the vga= option the kernel. But
> in addition to vga= it should be possible to pass a generic video=XxY
> for all framebuffer/drm drivers. With this change forcing a certain
> window size of VM displays is now much easier.
>
> Today the video= option is stored in a global fb_mode_option. But
> unfortunately only drm uses it.
>
> Note: this change introduces a small memleak if video=option is actually
> used because fb_mode_option is const. Most drivers use strsep to get to
> individual options. This could be fixed in a followup patch which always
> releases the option string in every caller of fb_get_options.
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> ---
> drivers/video/fbmem.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
> index 010d191..cde4619 100644
> --- a/drivers/video/fbmem.c
> +++ b/drivers/video/fbmem.c
> @@ -1930,6 +1930,9 @@ int fb_get_options(const char *name, char **option)
> options = opt + name_len + 1;
> }
> }
> + /* No match, pass global option */
> + if (!options && option && fb_mode_option)
> + options = kstrdup(fb_mode_option, GFP_KERNEL);
> if (options && !strncmp(options, "off", 3))
> retval = 1;
>
>
Queued for 3.14.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: <plagnioj@jcrosoft.com>, <linux-fbdev@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] fbmem: really support wildcard video=options for all fbdev drivers
Date: Wed, 8 Jan 2014 15:55:20 +0200 [thread overview]
Message-ID: <52CD58C8.3040703@ti.com> (raw)
In-Reply-To: <1387140035-12234-1-git-send-email-olaf@aepfle.de>
[-- Attachment #1: Type: text/plain, Size: 2043 bytes --]
On 2013-12-15 22:40, Olaf Hering wrote:
> Documentation/fb/modedb.txt states that video=option should be
> considered a global option. But video_setup and fb_get_options are not
> coded that way. Instead its required to boot with video=driver:option to
> set a given option in drvier. This is cumbersome because it requires to
> know in advance which driver will be active for a given board/kernel.
>
> The following patch implements the documented catchall for the fbdev
> drivers. It is now possible to boot with video=XxY without the need to
> know the active driver in advance. The specific case it tries to fix is
> syslinux in the SUSE installer which offers a menu to set a display
> resolution. Right now this just appends the vga= option the kernel. But
> in addition to vga= it should be possible to pass a generic video=XxY
> for all framebuffer/drm drivers. With this change forcing a certain
> window size of VM displays is now much easier.
>
> Today the video= option is stored in a global fb_mode_option. But
> unfortunately only drm uses it.
>
> Note: this change introduces a small memleak if video=option is actually
> used because fb_mode_option is const. Most drivers use strsep to get to
> individual options. This could be fixed in a followup patch which always
> releases the option string in every caller of fb_get_options.
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> ---
> drivers/video/fbmem.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
> index 010d191..cde4619 100644
> --- a/drivers/video/fbmem.c
> +++ b/drivers/video/fbmem.c
> @@ -1930,6 +1930,9 @@ int fb_get_options(const char *name, char **option)
> options = opt + name_len + 1;
> }
> }
> + /* No match, pass global option */
> + if (!options && option && fb_mode_option)
> + options = kstrdup(fb_mode_option, GFP_KERNEL);
> if (options && !strncmp(options, "off", 3))
> retval = 1;
>
>
Queued for 3.14.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
next prev parent reply other threads:[~2014-01-08 13:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-15 20:40 [PATCH] fbmem: really support wildcard video=options for all fbdev drivers Olaf Hering
2013-12-15 20:40 ` Olaf Hering
2013-12-16 14:10 ` Geert Uytterhoeven
2013-12-16 14:10 ` Geert Uytterhoeven
2014-01-08 13:55 ` Tomi Valkeinen [this message]
2014-01-08 13:55 ` Tomi Valkeinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52CD58C8.3040703@ti.com \
--to=tomi.valkeinen@ti.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=olaf@aepfle.de \
--cc=plagnioj@jcrosoft.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.