Revision as of 18:14, 19 January 2015

Login Screen Over Wayland

Summary

Change the Login screen that GDM uses to run on Wayland instead of X

Owner

Name: Ray Strode
Email: rstrode@redhat.com
Release notes owner:

Current status

Targeted release: Fedora 22
Last updated: 19 Jan 2015
Tracker bug: <will be assigned by the Wrangler>

Detailed Description

At the moment, a user can choose to log in to a Wayland session from the login screen, but the login screen itself always runs on top of X. The point of this change is to change that, and make the login screen always run on a Wayland session.

Benefit to Fedora

Fedora is steadily progressing toward the goal of replacing X uses with Wayland based uses instead. This is one step toward achieving that goal. The login session is sufficiently isolated and contained, that it makes an ideal first place to put Wayland by default. There should be little to no user visible impact with this change. Ideally the user won't be able to tell the difference between the login screen running on X versus the login screen running on Wayland.

Scope

Proposal owners: The main things that need be accomplished are:
- Change GDM to not start an X server at startup, instead run the login screen in Wayland mode
- Change X based user sessions to run on their own VT, since they can no longer piggyback off the login screen VT
- Come up with some answer for proprietary Nvidia driver users, since that stack doesn't yet support Wayland. One idea is to force the login session to use software-based mesa if the proprietary Nvidia driver is detected.

Other developers: We may need to get the mesa maintainer involved as part of a proprietary Nvidia driver handling, but also might not need to pending investigation.

Release engineering: This change doesn't affect release workflow

Policies and guidelines: This change doesn't affect packaging guidelines

Upgrade/compatibility impact

Shouldn't impact upgrades

How To Test

Boot machine
Ensure graphical login screen comes up
Jump to VT 6 and log in at console
Run "ps -ef | grep Xorg" and ensure Xorg isn't running
Return to VT 1
Try to log into a "GNOME" session
Log out
Try to log into a "GNOME Wayland" session
Log out

Steps 5 through 8 make sure that login screen is still able to log into user sessions.

User Experience

Should not have a noticeable impact in user experience

Dependencies

Might require changes to mesa packaging, but that's not known for sure yet.

Contingency Plan

Contingency mechanism: Revert to existing mechanism of login screen on Xorg
Contingency deadline: Beta Freeze
Blocks release? No
Blocks product? No

Documentation

No upstream documentation or bug links yet

Release Notes

@@ Line 1: / Line 1: @@
+= Login Screen Over Wayland =
-<!-- Self Contained or System Wide Change Proposal?
-Use this guide to determine to which category your proposed change belongs to.
-Self Contained Changes are:
-* changes to isolated/leaf package without the impact on other packages/rest of the distribution
-* limited scope changes without the impact on other packages/rest of the distribution
-* coordinated effort within SIG with limited impact outside SIG functional area, accepted by the SIG
-System Wide Changes are:
-* changes that does not fit Self Contained Changes category touching
-* changes that require coordination within the distribution (for example mass rebuilds, release engineering or other teams effort etc.)
-* changing system defaults
-For Self Contained Changes, sections marked as "REQUIRED FOR SYSTEM WIDE CHANGES" are OPTIONAL but FESCo/Wrangler can request more details (especially in case the change proposal category is
-improper or updated to System Wide category). For System Wide Changes all fields on this form are required for FESCo acceptance (when applies).
-We request that you maintain the same order of sections so that all of the change proposal pages are uniform.
--->
-<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->
-<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->
-= Login Screen Over Wayland <!-- The name of your change proposal --> =
 == Summary ==
-<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. -->
 Change the Login screen that GDM uses to run on Wayland instead of X
 == Owner ==
-<!--
-For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages.
-This should link to your home wiki page so we know who you are.
--->
 * Name: [[User:Rstrode| Ray Strode]]
-<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
 * Email: rstrode@redhat.com
 * Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> -->
 <!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
 * FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
--->
-<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)
-* Product:
-* Responsible WG:
 -->
@@ Line 59: / Line 26: @@
 == Detailed Description ==
+At the moment, a user can choose to log in to a Wayland session from the login screen, but the login screen itself always runs on top of X. The point of this change is to change that, and make the login screen always run on a Wayland session.
-At the moment, a user can choose to log in to a wayland session from the login screen, but the login screen itself runs on top of Xorg. The point of this change is to change that, and make the login screen run on a wayland session.
 == Benefit to Fedora ==
+Fedora is steadily progressing toward the goal of replacing X uses with Wayland based uses instead. This is one step toward achieving that goal. The login session is sufficiently isolated and contained, that it makes an ideal first place to put Wayland by default. There should be little to no user visible impact with this change. Ideally the user won't be able to tell the difference between the login screen running on X versus the login screen running on Wayland.
-Fedora is steadily progressing toward the goal of replacing Xorg uses with wayland based uses instead. This is one step toward achieving that goal. The login session is sufficiently isolated and contained, that it makes an ideal first place to put wayland by default. There should be little to no user visible impact with this change. Ideally the user won't be able to tell the difference between the login screen running on X versus the login screen running on wayland.
 == Scope ==
 * Proposal owners: The main things that need be accomplished are:
-** Change GDM to not start an X server at startup, instead run the login screen in wayland mode
+** Change GDM to not start an X server at startup, instead run the login screen in Wayland mode
 ** Change X based user sessions to run on their own VT, since they can no longer piggyback off the login screen VT
-** Come up with some answer for proprietary nvidia driver users, since that stack doesn't yet support wayland.  One idea is to force the login session to use software based mesa if the proprietary nvidia driver is detected.
+** Come up with some answer for proprietary Nvidia driver users, since that stack doesn't yet support Wayland.  One idea is to force the login session to use software-based mesa if the proprietary Nvidia driver is detected.
-* Other developers: We may need to get the mesa maintainer involved as part of a proprietary nvidia driver handling, but also might not need to pending investigation.
+* Other developers: We may need to get the mesa maintainer involved as part of a proprietary Nvidia driver handling, but also might not need to pending investigation.
-* Release engineering: N/A (doesn't affect release workflow)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+* Release engineering: This change doesn't affect release workflow
+* Policies and guidelines: This change doesn't affect packaging guidelines
-* Policies and guidelines: N/A (doesn't affect packaging guidelines) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-<!-- Do the packaging guidelines or other documents need to be updated for this feature?  If so, does it need to happen before or after the implementation is done?  If a FPC ticket exists, add a link here. -->
 == Upgrade/compatibility impact ==
-N/A (Shouldn't impact upgrades)
+Shouldn't impact upgrades
 == How To Test ==
-<!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done.  If it needs to be tested with different hardware or software configurations, indicate them.  The more specific you can be, the better the community testing can be.
+# Boot machine
+# Ensure graphical login screen comes up
-Remember that you are writing this how to for interested testers to use to check out your change implementation - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your change.
+# Jump to VT 6 and log in at console
+# Run "ps -ef | grep Xorg" and ensure Xorg isn't running
-A good "how to test" should answer these four questions:
+# Return to VT 1
+# Try to log into a "GNOME" session
-. What special hardware / data / etc. is needed (if any)?
+# Log out
-. How do I prepare my system to test this change? What packages
+# Try to log into a "GNOME Wayland" session
-need to be installed, config files edited, etc.?
+# Log out
-. What specific actions do I perform to check that the change is
-working like it's supposed to?
-. What are the expected results of those actions?
--->
-. Boot machine
-. Ensure graphical login screen comes up
-. Jump to VT 6 and log in at console
-. Run "ps -ef | grep Xorg" and ensure Xorg isn't running
-. Return to VT 1
-. Try to log into a "GNOME" session
-. Log out
-. Try to log into a "GNOME Wayland" session
-. Log out
 Steps 5 through 8 make sure that login screen is still able to log into user sessions.
 == User Experience ==
-<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
+Should not have a noticeable impact in user experience
-<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-N/A (should not have a noticeable impact in user experience)
 == Dependencies ==
-<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this change depends?  In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel change)? -->
+Might require changes to mesa packaging, but that's not known for sure yet.
-<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-Might require changes to mesa packagin, but that's not known for sure yet.
 == Contingency Plan ==
+* Contingency mechanism: Revert to existing mechanism of login screen on Xorg
-<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
+* Contingency deadline: Beta Freeze
-* Contingency mechanism: (What to do?  Who will do it?) Revert to existing mechanism of login screen on Xorg <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+* Blocks release? No
-<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
+* Blocks product? No
-* Contingency deadline: Beta Freeze <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
-* Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-* Blocks product? N/A (Shouldn't block release) <!-- Applicable for Changes that blocks specific product release/Fedora.next -->
 == Documentation ==
-<!-- Is there upstream documentation on this change, or notes you have written yourself?  Link to that material here so other interested developers can get involved. -->
+No upstream documentation or bug links yet
-<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-N/A (No upstream documentation or bug links yet)
 == Release Notes ==

Search

Changes/Login Screen Over Wayland: Difference between revisions