[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GDM status (again)

From: Ludovic Courtès
Subject: Re: GDM status (again)
Date: Sun, 29 Oct 2017 16:30:52 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

Hi Timothy,

Timothy Sample <address@hidden> skribis:

> Two months ago, Andy Wingo did a bunch of work on getting GDM working as
> a display manager for Guix [1]. Unfortunately, Andy had to step away
> from the task before getting everything working.

Thanks for taking it over!

> After clearing that up, I found out that GDM was unable to find the
> Gnome Shell. This is pretty tricky because Gnome Shell already depends
> on GDM, so you have to avoid a circular dependency. Other distros (I
> looked at Debian and Fedora) solve this by slicing out a “libgdm” output
> from the GDM sources, so that you can build “libgdm” without Gnome
> Shell, have Gnome Shell depend on “libgdm”, and then have GDM depend on
> Gnome Shell.

Do we really need a compile-time dependency (GDM in master doesn’t
depend on gnome-shell, after all), or can we just have a hard-coded
/run/current-system/bin/gnome-shell somewhere?  Granted, that’s not very
elegant, but it might be good enough?

Also, one can use GDM without using GNOME, so it would be best if GDM
didn’t depend on GNOME.

With this and the other changes you described, it looks like there’s
already a bunch of patches we could apply.  Would you like to send them?

> After making these changes, GDM should work and allow you to log
> in. This is where the problems I described earlier come it. The DBUS
> error happens because GDM never loads any “profile” scripts (e.g.,
> “/etc/profile”). This means that DBUS can’t find any “.session” files,
> which causes a lot of stuff to break. I tried to fix this by modifying
> the GDM source code to launch certain processes through a login shell
> (i.e., “bash -l -c "..."”), and indeed this let the DBUS session daemon
> find the “.session” files. Sadly, it just revealed fatal locale
> errors. (To be sure, I don’t really think it’s a good solution anyway. I
> just wanted to see what would happen.) This is where I gave up.

The way this was solved for SLiM was to run the window manager in a
login shell: see ‘exec-from-login-shell’ in (gnu services xorg).
Perhaps we could reuse the same approach?  Maybe we can wrap gdm itself
so that it’s launched from a login shell?

> If you’ve read this far, thank you! Sorry for the long story.

Well, thank *you* for the tireless investigation!

> Finally, some quick info about QEMU and testing GDM/Gnome. Gnome takes
> up a lot of memory, so “-m 1024” is a good idea. GDM runs X as non-root
> users, which means that X has to use the KMS/DRM system. Currently Guix
> sets up the Linux kernel without a direct rendering driver for the
> default QEMU graphics setup (“-vga std”). Fortunately, “-vga qxl” seems
> to solve this. (It looks like a driver for “-vga std” can be configured
> into the kernel with the “CONFIG_DRM_BOCHS” flag, but I have not tested
> this.) In QEMU, you can switch VTs by pressing Crtl-Alt-2 to get to the
> QEMU shell, and then typing “sendkey ctrl-alt-fN” where N is the VT you
> want to switch to.

Looks like another patch we could apply: defaulting to “-vga qxl”.  Or
is there any downside?

Thanks for the detailed report, and thanks in advance for the patches
you described!  :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]