All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Charles Lohr <lohr85@gmail.com>,
	Linux Fbdev development list <linux-fbdev@vger.kernel.org>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: David Airlie <airlied@redhat.com>,
	dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: fbcon non-desktop display use
Date: Thu, 15 Mar 2018 09:32:03 +0000	[thread overview]
Message-ID: <CAKMK7uER_hCNqrfAkHYsece7FNc05Cwd_PTkx9Hfv2wUuPjL4A@mail.gmail.com> (raw)
In-Reply-To: <CAGu26P8B-JNPnRrvgKCirE+rE2vGpgo56Hxh_tKYxY2jrwcNRQ@mail.gmail.com>

On Thu, Mar 15, 2018 at 4:32 AM, Charles Lohr <lohr85@gmail.com> wrote:
> There was a patch submitted by Keith Packard which prevents fbcon from using
> non-desktop displays, but this breaks vive, and other HMD development/use on
> embedded and other fbdev systems (
> https://patchwork.kernel.org/patch/10053989/ ).
>
> Even if the vive is the only device connected, it will still not permit it
> to be operated.  See https://github.com/linux-sunxi/linux-sunxi/issues/291
> for dri with a lot of debugging turned on.
>
> I can understand that most users would probably prefer that the vive isn't
> automatically used if no other displays are available, however, the current
> behavior prevents use of the vive on all devices that use fbdev for their
> primary output.
>
> This patch allows enabling of non-desktop devices both as a kernel command
> line as well as by setting
> /sys/module/drm_kms_helper/parameters/drm_fbdev_permit_non_desktop.

Why exactly are you developing new userspace on top of fbdev? fbdev
never ever supported HMDs in any meaningful fashion (those things
didn't exist 20 years ago when fbdev was designed), and we have fbdev
in feature freeze mode since a few years now. Please explain a bit
more about what exactly you're trying to do here, and what's running
in userspace that makes you require fbdev.

Adding fbdev lists&maintainer.

Also please note that for graphics stuff we require a fully open
sourced userspace side of the stack when adding new support, which
this very much feels like. See:

https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements>

> I've never sent an email to the kernel devel list, so I'm still a little
> nervous.  Especially because this is against a different branch, and I'm
> starting to think that I should be messaging there, but this is something
> that really needs to go upstream.

Welcome to upstream! You're doing perfectly fine. We're trying really
hard to be welcoming and respectful in the graphics subsystem, and
have an enforced Code of Conduct to that effect:

https://dri.freedesktop.org/docs/drm/gpu/introduction.html#code-of-conduct
-Daniel



>
> Signed-off-by:
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c
> b/drivers/gpu/drm/drm_fb_helper.c
> index 035784ddd..8bfaf79ff 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -55,6 +55,11 @@ MODULE_PARM_DESC(drm_fbdev_overalloc,
>                  "Overallocation of the fbdev buffer (%) [default="
>                  __MODULE_STRING(CONFIG_DRM_FBDEV_OVERALLOC) "]");
>
> +static bool drm_fbdev_permit_non_desktop;
> +module_param(drm_fbdev_permit_non_desktop, bool, 0644);
> +MODULE_PARM_DESC(drm_fbdev_permit_non_desktop,
> +               "Allow the framebuffer to use non-desktop displays
> [default=off]");
> +
>  static LIST_HEAD(kernel_fb_helper_list);
>  static DEFINE_MUTEX(kernel_fb_helper_lock);
>
> @@ -2109,7 +2114,7 @@ static bool drm_connector_enabled(struct drm_connector
> *connector, bool strict)
>  {
>         bool enable;
>
> -       if (connector->display_info.non_desktop)
> +       if (connector->display_info.non_desktop &&
> !drm_fbdev_permit_non_desktop)
>                 return false;
>
>         if (strict)
>
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Charles Lohr <lohr85@gmail.com>,
	Linux Fbdev development list <linux-fbdev@vger.kernel.org>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: David Airlie <airlied@redhat.com>,
	dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: fbcon non-desktop display use
Date: Thu, 15 Mar 2018 10:32:03 +0100	[thread overview]
Message-ID: <CAKMK7uER_hCNqrfAkHYsece7FNc05Cwd_PTkx9Hfv2wUuPjL4A@mail.gmail.com> (raw)
In-Reply-To: <CAGu26P8B-JNPnRrvgKCirE+rE2vGpgo56Hxh_tKYxY2jrwcNRQ@mail.gmail.com>

On Thu, Mar 15, 2018 at 4:32 AM, Charles Lohr <lohr85@gmail.com> wrote:
> There was a patch submitted by Keith Packard which prevents fbcon from using
> non-desktop displays, but this breaks vive, and other HMD development/use on
> embedded and other fbdev systems (
> https://patchwork.kernel.org/patch/10053989/ ).
>
> Even if the vive is the only device connected, it will still not permit it
> to be operated.  See https://github.com/linux-sunxi/linux-sunxi/issues/291
> for dri with a lot of debugging turned on.
>
> I can understand that most users would probably prefer that the vive isn't
> automatically used if no other displays are available, however, the current
> behavior prevents use of the vive on all devices that use fbdev for their
> primary output.
>
> This patch allows enabling of non-desktop devices both as a kernel command
> line as well as by setting
> /sys/module/drm_kms_helper/parameters/drm_fbdev_permit_non_desktop.

Why exactly are you developing new userspace on top of fbdev? fbdev
never ever supported HMDs in any meaningful fashion (those things
didn't exist 20 years ago when fbdev was designed), and we have fbdev
in feature freeze mode since a few years now. Please explain a bit
more about what exactly you're trying to do here, and what's running
in userspace that makes you require fbdev.

Adding fbdev lists&maintainer.

Also please note that for graphics stuff we require a fully open
sourced userspace side of the stack when adding new support, which
this very much feels like. See:

https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements>

> I've never sent an email to the kernel devel list, so I'm still a little
> nervous.  Especially because this is against a different branch, and I'm
> starting to think that I should be messaging there, but this is something
> that really needs to go upstream.

Welcome to upstream! You're doing perfectly fine. We're trying really
hard to be welcoming and respectful in the graphics subsystem, and
have an enforced Code of Conduct to that effect:

https://dri.freedesktop.org/docs/drm/gpu/introduction.html#code-of-conduct
-Daniel



>
> Signed-off-by:
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c
> b/drivers/gpu/drm/drm_fb_helper.c
> index 035784ddd..8bfaf79ff 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -55,6 +55,11 @@ MODULE_PARM_DESC(drm_fbdev_overalloc,
>                  "Overallocation of the fbdev buffer (%) [default="
>                  __MODULE_STRING(CONFIG_DRM_FBDEV_OVERALLOC) "]");
>
> +static bool drm_fbdev_permit_non_desktop;
> +module_param(drm_fbdev_permit_non_desktop, bool, 0644);
> +MODULE_PARM_DESC(drm_fbdev_permit_non_desktop,
> +               "Allow the framebuffer to use non-desktop displays
> [default=off]");
> +
>  static LIST_HEAD(kernel_fb_helper_list);
>  static DEFINE_MUTEX(kernel_fb_helper_lock);
>
> @@ -2109,7 +2114,7 @@ static bool drm_connector_enabled(struct drm_connector
> *connector, bool strict)
>  {
>         bool enable;
>
> -       if (connector->display_info.non_desktop)
> +       if (connector->display_info.non_desktop &&
> !drm_fbdev_permit_non_desktop)
>                 return false;
>
>         if (strict)
>
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2018-03-15  9:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-15  3:32 fbcon non-desktop display use Charles Lohr
2018-03-15  9:32 ` Daniel Vetter [this message]
2018-03-15  9:32   ` Daniel Vetter
2018-03-15 18:30 ` Keith Packard
2018-03-15 20:03   ` Charles Lohr
2018-03-15 20:03     ` Charles Lohr
2018-03-15 20:11     ` Daniel Vetter
2018-03-15 20:11       ` Daniel Vetter

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=CAKMK7uER_hCNqrfAkHYsece7FNc05Cwd_PTkx9Hfv2wUuPjL4A@mail.gmail.com \
    --to=daniel@ffwll.ch \
    --cc=airlied@redhat.com \
    --cc=b.zolnierkie@samsung.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=lohr85@gmail.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.