From: Ezequiel Garcia <ezequiel@collabora.com>
To: buildroot@busybox.net
Subject: [Buildroot] xorg with nodm/xdm init.d script conflicts causes blank screen
Date: Fri, 13 Sep 2019 22:08:45 +0100 [thread overview]
Message-ID: <348ab096ff9aeb8f448af5c8bddf15fdac9a61ed.camel@collabora.com> (raw)
In-Reply-To: <20190913194112.49f3fa68@windsurf.home>
Hello everyone,
On Fri, 2019-09-13 at 19:41 +0200, Thomas Petazzoni wrote:
> Hello Tudor,
>
> Thanks for your report. I'm adding in Cc Bernd who added the Xorg init
> script, and Ezequiel Garcia, who contributed the nodm package.
>
Thanks for the report and thanks for Ccing me. See my comments
below, but beware: it's been a long while, so the little
X understanding I ever had is today even smaller.
> On Fri, 13 Sep 2019 16:24:52 +1000
> Tudor Holton <tudor@smartguide.com.au> wrote:
>
> > Hello awesome buildroot people, :-)
> >
> > If I select the X.org server BR2_PACKAGE_XSERVER_XORG_SERVER and a
> > display manager like BR2_PACKAGE_NODM, then I get 2 files in
> > /etc/init.d:
> >
> > S40xorg which starts the server /usr/sbin/Xorg first and
> > S90nodm which then tries to start another copy of Xorg (to call
> > /etc/X11/Xsession and get everything on the display).
> >
> > Obviously, this doesn't work because nodm can't start a second X server,
> > and the visual result is a black screen. The only solution I can see is
> > a post-build script to remove the S40xorg script to disable X and allow
> > nodm to manage X.
>
> So it means that starting /usr/bin/nodm in fact starts another X.org
> server. I would have expected S40xorg to start the X.org server, and
> then S90nodm to start the display manager inside the X.org server
> started by S40xorg, but apparently it's not the case.
>
Normally, display managers start X. E.g.:
gdm:
https://github.com/GNOME/gdm/blob/master/daemon/gdm-server.c#L710
nodm:
https://github.com/spanezz/nodm/blob/master/xserver.c#L159
> > I've tried looking for:
> > (a) A way to tell Xorg that nodm is the default application
> > (b) A way to tell nodm that an Xorg is already running (the S90nodm
> > script reads /etc/default/* but NODM_XINIT is now ignored and there
> > aren't any other obvious options to nodm)
> > (c) To use a different display manager, xdm, but they all seem to insert
> > an init.d file that's in the range S90-S99 and follow the same
> > presumption (that X has not started)
>
> So if all display manager all start their own X.org server instance, it
> means that perhaps S40xorg should only be installed if there's no
> display manager enabled ?
>
I guess that's right.
> > What's the best (future-proof) approach to getting a display manager
> > working with X in buildroot?
>
Keep in mind that nodm is _not_ a display manager, just as it's name implies.
It's for embedded devices that don't want to login.
> Bernd, Ezequiel, any suggestion here ?
>
When nodm was introduced, xorg-server didn't have the sysv init script.
I assume it was added because Bernd needed to launch X without any session,
but I don't truly understand the reasons for that route, as opposed to
using a display manager. Or nodm, in case a fixed user login, no security
is needed, as in a e.g. kiosk thing.
I haven't checked if it's possible, but I guess we can make some hidden
config symbol PROVIDES_X_DISPLAY_MANAGER for display managers to select,
and then use it to restrict the xorg server sysv init so it's available
only if no display manager was selected.
Curious about the unfolding,
Ezequiel
> > P.S. (As an aside, why don't more buildroot init scripts use
> > /etc/default config files?)
>
> Because we need more contributions to make our init scripts consistent
> and use /etc/default config files! :-)
>
> Best regards,
>
> Thomas
next prev parent reply other threads:[~2019-09-13 21:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-13 6:24 [Buildroot] xorg with nodm/xdm init.d script conflicts causes blank screen Tudor Holton
2019-09-13 17:41 ` Thomas Petazzoni
2019-09-13 21:08 ` Ezequiel Garcia [this message]
2019-11-09 16:11 ` Ezequiel Garcia
2019-11-17 19:28 ` Arnout Vandecappelle
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=348ab096ff9aeb8f448af5c8bddf15fdac9a61ed.camel@collabora.com \
--to=ezequiel@collabora.com \
--cc=buildroot@busybox.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox