summaryrefslogtreecommitdiff
path: root/daemon/gdm-local-display.c
Commit message (Collapse)AuthorAgeFilesLines
* gdm-local-display: Remove dead codeAlessandro Bono2023-04-281-4/+0
|
* local-display: use G_DECLARE_FINAL_TYPENiels De Graef2018-12-231-10/+5
|
* launch-environment: use wayland for initial-setupRay Strode2018-08-311-8/+4
| | | | | | | | | | | While we've been using wayland by default for the login screen for a long time, and for the user session for somewhat less time, we never switched initial setup over. It's still using X11 for no good reason. This commit changes initial-setup to use wayland by default like everything else.
* local-display: don't use wayland with gnome-initial-setupRay Strode2015-02-241-0/+12
| | | | | | | | | | | We haven't yet decided to use gnome-initial-setup on wayland. Before we can, we need to create a wayland based session file for it anyway. This commit makes sure we properly fall back to X11 for gnome-initial-setup. https://bugzilla.gnome.org/show_bug.cgi?id=745139
* display: add session-type propertyRay Strode2015-02-181-1/+4
| | | | | | | | | | | The session-type property is analagous to the sd_login session type. It can be either "x11" or "wayland". This helps us decide whether to start a wayland session or an X session. https://bugzilla.gnome.org/show_bug.cgi?id=744764
* launch-environment: add session-type propertyRay Strode2015-02-181-0/+1
| | | | | | | | | | The session-type property is analagous to the sd_login session type. It can be either "x11" or "wayland". This helps us decide whether to start a wayland session or an X session. https://bugzilla.gnome.org/show_bug.cgi?id=744764
* display: add new session-class propertyRay Strode2015-02-181-0/+9
| | | | | | | | | | | | | | The session-class property is analagous to the sd_login session class. It can be either "greeter" or "user". This helps us decide whether or not to add a launch environment to the display. We need this because some displays go straight to a user session. https://bugzilla.gnome.org/show_bug.cgi?id=744764
* local-display: don't manage automaticallyRay Strode2015-02-181-9/+0
| | | | | | | | Now that local displays register themselves and registration leads to the displays getting managed, we don't need to manage explicitly (and prematurely). https://bugzilla.gnome.org/show_bug.cgi?id=744764
* session: start login screen using session wrappersRay Strode2015-02-181-114/+9
| | | | | | | | | | | | | | | Since we have the wrappers, let's use them for the login screen, too, when we can. This commit removes GdmServer from GdmLocalDisplay, since starting the X server should be handled implicitly by gdm-x-session, now. All the old logic is now in a new GdmLegacyDisplay object, that will remain for cases where gdm-x-session doesn't work. (ConsoleKit systems, non-seat0 displays, etc) https://bugzilla.gnome.org/show_bug.cgi?id=744764
* display: get rid of more simple slave code.Ray Strode2015-02-181-0/+107
| | | | | | | This commit moves GdmServer to GdmLocalDisplay, and XDMCP connection retries to GdmXdmcpDisplay. https://bugzilla.gnome.org/show_bug.cgi?id=744764
* display: start greeter/chooser session from display objectRay Strode2015-02-181-0/+40
| | | | | | | | | | | We're trying to get rid of the slave code, so we need to move responibility for launching the greeter to the display objects. This commit changes the display classes to set up a launch environment that the base class runs. https://bugzilla.gnome.org/show_bug.cgi?id=744764
* display: merge GdmStaticDisplay and GdmTransientDisplayRay Strode2015-02-181-0/+117
They basically do the same thing with very minor differences, so merge them into a new GdmLocalDisplay object. https://bugzilla.gnome.org/show_bug.cgi?id=744764
View Lorry Controller Status