Tag Archives: lightdm

Understanding lightdm.conf

Based on the questions I’ve seen on AskUbuntu, lightdm.conf is one of the most misunderstood files on your system. So, I decided I’d write a post on how you can easily modify this file and what the modification are useful for. I hope to show how to modify the most asked about settings.

Safely Modifying lightdm.conf

Before you do anything to your lightdm.conf file, you should make a backup, simply run:

sudo cp /etc/lightdm/lightdm.conf /etc/lightdm/lightdm.conf.old

Once you’ve made a backup, the simplest and safest way to modify lightdm.conf is to use lightdm-set-defaults. lightdm-set-defaults was written so that lightdm.conf could be modified via script, but you can also use it to easily make changes. I’ve made several changes to this tool to add new features that I needed, and best of all, I even wrote a manpage for it, which should show up in raring at some point. If you’re not using raring, then just run /usr/lib/lightdm/lightdm-set-defaults with no arguments and you’ll get a clear picture on what it can do.

Usage:
lightdm-set-defaults [OPTION...] - set lightdm default values

Help Options:
-h, --help Show help options

Application Options:
-d, --debug Enable debugging
-k, --keep-old Only update if no default already set
-r, --remove Remove default value if it's the current one
-s, --session Set default session
-g, --greeter Set default greeter
-a, --autologin Set autologin user
-i, --hide-users Set greeter-hide-users to true or false
-m, --show-manual-login Set show-manual-login to true or false
-R, --show-remote-login Set show-remote-login to true or false
-l, --allow-guest Set allow-guest to true or false

You can also edit the file manually, but in either case, manual edit or set-defaults, you’ll need to use sudo. And now that you know how to modify the file, let’s cover what the most frequently asked about items are.

Disabling Guest Login

Some people really get annoyed by guest login, so if you want to disable it, simply use:

sudo /usr/lib/lightdm/lightdm-set-defaults --allow-guest false

Or, you can manually add the following line in the [SeatDefaults] section:

allow-guest=false

The default for this option is true, so if unset, the guest account will be enabled.  Note: See how great the command option for lightdm-set-defaults was named? Whoever added that was a genius.

Hiding the User List

If you don’t want a user list to be displayed by the greeter, you can enable this option. This should also be used with the enabling manual login (below) or logging in may be a challenge (actually I’ve never tried one without the other, I’m not sure what will happen).

sudo /usr/lib/lightdm/lightdm-set-defaults --hide-users true

Or, you can manually add the following line in the [SeatDefaults] section:

greeter-hide-users=true

The default for this option is false, so if unset, you will get a user list in the greeter.

Show Manual Login Box

If you previously hid your user list and would like a box where you can manually type in a user name then this option is for you.

sudo /usr/lib/lightdm/lightdm-set-defaults --show-manual-login true

Or, you can manually add the following line in the [SeatDefaults] section:

greeter-show-manual-login=true

The default for this option is false, so if unset, you won’t get a manual login box.

Autologin

You can enable autologin by specifying the autologin user.

sudo /usr/lib/lightdm/lightdm-set-defaults --autologin username

Or, you can manually add the following line in the [SeatDefaults] section:

autologin-user=username

There are other autologin related options which you may want to set, but none of these can be set using lightdm-set-defaults:

To change how long the greeter will delay before starting autologin.  If not set, the delay is 0, so if you want this to be 0, you don’t need to change it.  Note: the default for all unset integers in the [SeatDefaults] section is 0.

autologin-user-timeout=delay

To enable autologin of the guest account:

autologin-guest=true

Run a Command When X Starts, When The Greeter Starts, When the User Session Starts

When lightdm starts X you can run a command or script, like xset perhaps.

display-setup-script=[script|command]

You can do something similar when the greeter starts:

greeter-setup-script=[script|command]

or when the user session starts:

session-setup-script=[script|command]

Change the Default Session

If you want a different session for the default, you can modify this option. I think that the greeter will default to give you the last session you chose, so this option will only change the default session. Note: The session switcher will only show up if you have more than one VALID session; a valid session is one that points to a valid executable. By default in 12.10 you will have a session file for gnome-shell, but gnome-shell won’t be installed, so the session is invalid, leaving you with a single valid session (Ubuntu), and hence no session selector!

/usr/lib/lightdm/lightdm-set-defaults --session [session name]

Or, you can manually add the following line in the [SeatDefaults] section:

user-session=true

The list of user sessions is in /usr/share/xsessions, although even that location is configurable (see Advanced Options).

You can change the default greeter in the same manner, using –greeter for lightdm-set-defaults or greeter-session for the config file. The list of installed greeters is in /usr/share/xgreeters.

Advanced Options and All Other Options

There is no manpage for lighdm.conf, but there is an example that lists all the options and a bit about what they do, just look in /usr/share/doc/lightdm/lightdm.conf.gz.  If you use vim, you can just edit the file and it will be automagically ungzipped for you, users of other editors are on their own.

Tagged , ,

ubuntu-bug is for lightdm, Soon!

A bug triager’s best friend is ubuntu-bug. Special per-package hooks in /usr/share/apport/package-hooks collect logs and config files that make bug triage and analysis much easier. The scripts also help to avoid the “Can you please post the … file?” back and forth that tends to waste time and many time ends up in an incomplete bug being marked expired. (As an aside when a bug submitter is asked for more info, the bug is marked Incomplete until it is updated, if it’s not updated in 60 days, it expires).

What does this have to do with lightdm? So tonight I shared my lightdm blog post with some people and Bryce Harrington suggested that I write an apport script for lightdm. I mentioned this brilliant plan to Robert Ancell and it turns out that lightdm has one already! Well my work is done!  Except…  The existing script wasn’t being packaged or installed, was collecting logs with the wrong (old) names, and didn’t collect the configs. All of that is fixed tonight with a MP I made, based on the code that Xorg’s apport script uses. Once it’s merged and released (probably not until R opens) we will have an apport script for lightdm. Once that happens, you can file a bug by simply typing:

ubuntu-bug lightdm

There’s no apport script for any of the the greeters, at least not that I know of for unity-greeter or lightdm-gtk-greeter, but they’d need the same data. The only thing that this script doesn’t do is get a screencap/picture, that’s up to you guys.

Tagged , , ,

Lightdm Bugs: What You (the Bug Filer) Should Know

I’ve been spending some time off and on cleaning and working on up the bugs in the lightdm project. Unfortunately someone who takes on this task, lightdm ends up with a lot of bugs that are not necessarily lightdm bugs and also lots of bugs with incomplete information. In a perfect world, everyone who was going to file a lightdm bug would read this, for now I’ll settle for spreading this information to anyone who reads my blog.

First a bit about the architecture. The job of the display manager (prior to lightdm) was to be a daemon, manage logins and sessions, run the display server, and provide a GUI to interact withe the user. Unfortunately since everyone has a favorite GUI technology, we ended up with a ton of different Display Managers (GDM, XDM, KDM, etc). The idea with lightdm was to separate the back-end work from the GUI. Everyone could re-use the back-end (lighdtm) and write their own GUI, also called a greeter, on top. So that’s where we are now, lightdm is a daemon process that manages everything, and a greeter, usually unity-greeter for Ubuntu or lightdm-gtk-greeter for Xubuntu deals with the user interaction. A PDF presentation on the architecture from the Desktop Summit is available here. Note: I assume Kubuntu uses the lightdm-qt-greeter but I’m not sure, if you know please comment here.

So why should you care about the architecture just to file a bug? The reason is that if you get your bug to the right package it will speed up the response. So here’s a real basic decision tree for you to follow when deciding what package to file against:

  1. Is the issue with something you’re seeing on the screen?  If so, it’s probably a greeter bug. If you’re using default Ubuntu, file against unity-greeter. If you’re using Xubuntu file against lightdm-gtk-greeter. Special case: Did the greeter load but the graphics look a little screwed up?  That could be an Xorg driver issue.
  2. If no greeter started, if you started in “low graphics mode”, or it doesn’t fit with case number 1 above, file it against lightdm and we can move it later if we need to.
For all bugs you will also get a much better response if you provide full and correct information from the beginning. This means providing the following details:
  • Like all Ubuntu bugs, you need to include steps to reproduce.
  • For all bugs we need the version of ligthdm you are using and the name of and the version of the greeter you are using. If you don’t know which greeter you are using, you can look at /etc/lightdm/lightdm.conf and check out the line that contains greeter-session.
  • If you have a greeter problem, for example, some of the graphical elements don’t look correct or you have problems entering your username, please include a screen-cap.
  • If you’ve messed with the standard lightdm config file, please attach /etc/lightdm/lightdm.conf to the bug.
  • For all greeter and lightdm bugs it helps us to include the contents of /var/log/lightdm.  You can tar them all up and post them. The logs will include your username, if you don’t want this to be known, then edit the logs and replace it with something else. The logs require root to read, so here’s a gather snippet you can copy:
sudo tar -cvzf ~/lightdm_logs.tgz /var/log/lightdm/*

If you plan on filing a bug against lightdm or a greeter following these steps can really help us out and hopefully get you a resolution quicker.  Thanks!

Tagged , , ,

Forcing lightdm to Use a Specific Resolution

This morning I was debugging a problem in unity-greeter and I suspected that it might be related to the resolution of the system I was using. Since I was live booting it was a pain to make changes, mainly because I didn’t have all my standard tools (or web access). I ended up messing around with xorg.conf files for awhile, without much success (this reminded me of college, but not pleasantly). After some other searches, I ended up settling on this method:

For this example, I wanted a resolution of 1024×600.

  1. Login to my system
  2. Open a terminal and run cvt 1024 600
  3. Copy the resulting output, minus ModeLine portion
  4. mfisch@caprica:~$ cvt 1024 600
    # 1024x600 59.85 Hz (CVT) hsync: 37.35 kHz; pclk: 49.00 MHz
    Modeline "1024x600_60.00"   49.00  1024 1072 1168 1312  600 603 613 624 -hsync +vsync
    
  5. Run xrandr –newmode
  6. mfisch@caprica:~$ xrandr --newmode "1024x600_60.00"   49.00  1024 1072 1168 1312  600 603 613 624 -hsync +vsync
    
  7. Run xrandr –addmode LVDS 1024x600_60.00. (Note that there are several displays that xrandr shows, I wanted to change my main laptop display, LVDS, you may want to change another. Run xrandr without arguments to see all the displays.)
  8. Run xrandr –output LVDS –mode 1024x600_60.00
  9. If that switches your resolution and looks right, then lets make it permanent.
  10. Edit: /etc/lightdm/lightdm.conf, add this line (note you can choose a different path:
  11. display-setup-script=/usr/bin/lightdmxrandr
  12. Make a new file called /usr/bin/lightdmxrandr, make it a shell script that just executes lines 4, 5, and 6 from above
  13. #!/bin/sh
    xrandr --newmode "1024x600_60.00"   49.00  1024 1072 1168 1312  600 603 613 624 -hsync +vsync
    xrandr --addmode LVDS 1024x600_60.00
    xrandr --output LVDS --mode 1024x600_60.00
    
  14. Make /usr/bin/lightdmxrandr executable, logout, and restart lightdm (sudo initctl restart lighthdm)
  15. Enjoy your new resolution!

Here are the two links that helped me piece this together:

How change display resolution settings using xrandr
How can I make xrandr customization permanent?

Tagged , ,

So You Want to Write a LightDM Greeter…

What is a LightDM Greeter?

LightDM is a lightweight display manager that splits the responsibilities of a display manager between the server and the UI, which is known as a greeter.  When you login to Ubuntu you are shown the Unity Greeter, but all the back-end session management and authentication is provided by the LightDM daemon, and functionality that a greeter needs is provided by liblightdm. LightDM exposes a set of APIs that allow you easily and quickly write your own greeter using your choice of languages.  As long as you can interact with LightDMs GObject API, you can use any language you want.

Why Write a Greeter?

Given all that, why would you want to write a greeter?  The Unity Greeter looks pretty nice after all.  In my case, I had special requirements that necessitated a change to the UI and some extra processing for the session.  During the course of this work, I wrote a greeter based on the sample GTK greeter that comes with LightDM and then applied my modifications.  I originally wrote it in C, but then moved to Python for easier integration into my other code.  My hope is that you can re-use some of my learnings below and write your own greeter that suits the needs of your distro or project.

The Unity Greeter

Let’s Get Started

This post is designed to give you an overview of the greeter and how it works. The code for my very simple example greeter, which is available here, is commented to the point where I hope it will answer your code questions. After reading this post, walk through the code and I think the process will make sense. Once you understand this code and want to do more advanced things, you should check out the GTK example greeter, which is part of the LightDM GTK+ Greeter project.

Note: You can also get my code from launchpad here, or via bzr with bzr branch lp:~mfisch/+junk/example-greeter

How LightDM Authentication Works

The first thing to understand is the way LightDM authenticates is a multi-step process and that this process will guide how we write our greeter.

  1. User enters a username and clicks the Login button.
  2. LightDM passes the username to PAM and responds back to the greeter with a prompt, such as “Password:”.
  3. User enters the password and the greeter passes it back to LightDM.
  4. LightDM authenticates with PAM and returns success or failure back to the greeter.
  5. LightDM may also return a message, such as “Login failed”, which needs to be displayed to the user.
  6. If the authentication succeeds, the greeter starts a session.

Program Flow

The diagram below shows the flow between the greeter, the top row, and the LightDM backend, the bottom section. This flow assumes a successful login as we don’t show the failure case for simplicity’s sake.

Flow of the greeter during login

Looking at the Code

At this point you probably want to look at the code and compare it to the flow in the diagram. The code is heavily commented and hopefully the diagram makes it easy to follow.

Screenshots of the Example Greeter

As you can see our greeter isn’t pretty, but it works. Hopefully this gives you an idea of the prompt re-use, which is pretty standard in greeters I’ve seen. Making this look nice is left as an exercise to the artistic reader.

Installing Your Greeter

Your greeter will minimally include an executable and a desktop file. The executable is usually installed somewhere in the path, like /usr/bin. The .desktop file goes into /usr/share/xgreeters and tells LightDM how to launch your greeter. The name of the .desktop file defines what you need to put in LightDM’s conf file. Additionally your greeter may install a configuration file, typically in /etc/lightdm and a Gtk UI file, if you’re using GTK. Once your greeter is in place you need to tell LightDM to use it. If you’re just testing things, you can edit /etc/lightdm/lightdm.conf and set greeter-session=example-greeter. What you set here has to match the name of your desktop file as mentioned above. If you plan to do this in a package install, you need to use /usr/lib/lightdm-set-defaults, which allows you to set a few defaults via a script. In this case we’d call /usr/lib/lightdm/lightdm-set-defaults –greeter=example-greeter. You can run that script with no arguments to see it’s full capabilities and options.

Once you install your greeter, you need to restart LightDM with sudo initctl restart lightdm. If it works, great! If not, check out the Debugging section below.

Debugging

A few hints on debugging your greeter. Anything you print to stderr in your greeter ends up in /var/log/lightdm/x-0-greeter.log. I find that keeping that open in a separate console dedicated to looking at this log always helps. Since the logs get deleted every time the greeter restarts, this is your best option: sudo tail -f /var/log/lightdm/x-0-greeter.log

LightDM itself may have useful logs if your configuration is broken, they’re in /var/log/lightdm/lightdm.log, and again you need sudo to view the logs.

Debugging a greeter with a debugger can be tricky, so I’ve found that printing debug into to stderr is your best option. However, the greeter seems simple enough that this method usually works fine.

Also you almost always want to do your development of a greeter in a VM. Alternatively, you can run lightdm in test mode with lightdm –test-mode, which allows you to run lightdm from the command-line as an unprivileged user. This will start your greeter in a window inside your existing session.

Finally you may get your greeter into a state where it keeps trying to launch and keeps failing. In a VM this will result in the window popping between X and a text terminal as it keeps failing. Just wait a bit and LightDM will eventually give up on your greeter and you can drop into a console and see what’s wrong.

Documentation

LightDM’s API is defined here. Everything I used in the example greeter focuses on the Greeter section. If you want to do more advanced things like allow the user to shutdown the system from the greeter, or query the list of available sessions, please check the other sections.

I also highly recommend walking through the GTK Greeter for seeing how some of these more advanced options work.

A word of caution if you’re going to use Python, in version 1.0.6 of LightDM, the introspection bindings for Python were broken. They’re fixed on trunk, but I don’t think a fix has made it into a release yet (as of Feb 6, 2012).

Summary

This example code barely covers the surface of what you need to do in order to make a good greeter, but it should help you get started. I recommend for follow-up that you read through example the GTK example greeter, which comes in the source for the LightDM package. You can use that knowledge to make your greeter look much nicer and add features like accessibility (a11y) and options like shutdown/restart/etc from your greeter.

Tagged , , ,