Bug 25749 - plymouth doesn't work well when run from another vt
Summary: plymouth doesn't work well when run from another vt
Status: RESOLVED FIXED
Alias: None
Product: plymouth
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Ray Strode [halfline]
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-12-21 14:59 UTC by Ray Strode [halfline]
Modified: 2010-06-04 08:20 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Ray Strode [halfline] 2009-12-21 14:59:14 UTC
Plymouth's VT handling code isn't really good enough to run plymouth from any vt other than the initial vt.

1) The drm renderer assumes plymouth starts out "active" even before the initial vt switch is finished
2) the console code puts tty0 in PROCESS mode early on.  This means we put initial active vt in PROCESS mode, not the one we want to be on.  This means we won't get notifications when leaving the right vt, and will get spurious notifications when entering the wrong vt
3) the console code has a state variable that says whether we need to call VT_WAITACTIVE, but it doesn't clear the state variable when the VT is switched behind plymouth's back.
Comment 1 Scott James Remnant 2009-12-22 19:43:38 UTC
Notes from brief IRC discussion:

 - ply_console_t is intended to be "the console which has the active vt", but is being used in ways that really mean "plymouth's vt"

 - there isn't a race-free way to always know that the active vt is plymouth's vt

 - rename ply_console_t to ply_vt_t, the operations on it are all the things we want to do to plymouth's VT anyway (VT_PROCESS, set mode, etc.)

 - ply_vt_new (state->default_tty)

 - What about renderers that don't need a VT (x11?)

 - new terminal from vt - for the default case?

 - should ply_console remain just for get_active_vt and set_active_vt which can be done on /dev/tty0 (though they can be done on /dev/tty7 just as easily)
Comment 2 Ray Strode [halfline] 2010-05-10 07:56:16 UTC
Scott fixed this up a while ago.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.