Systemd/src/login/logind-seat.h

77 lines
1.9 KiB
C
Raw Normal View History

/* SPDX-License-Identifier: LGPL-2.1+ */
#pragma once
2011-05-24 00:19:22 +02:00
typedef struct Seat Seat;
#include "list.h"
#include "logind-session.h"
struct Seat {
Manager *manager;
char *id;
char *state_file;
LIST_HEAD(Device, devices);
Session *active;
Session *pending_switch;
2011-05-24 00:19:22 +02:00
LIST_HEAD(Session, sessions);
2011-05-25 00:55:58 +02:00
logind: introduce session "positions" logind has no concept of session ordering. Sessions have a unique name, some attributes about the capabilities and that's already it. There is currently no stable+total order on sessions. If we use the logind API to switch between sessions, we are faced with an unordered list of sessions we have no clue of. This used to be no problem on seats with VTs or on seats with only a single active session. However, with the introduction of multi-session capability for seats without VTs, we need to find a way to order sessions in a stable way. This patch introduces session "positions". A position is a simple integer assigned to a session which is never changed implicitly (currently, we also don't change it explicitly, but that may be changed someday). For seats with VTs, we force the position to be the same as the VTnr. Without VTs, we simply find the lowest unassigned number and use it as position. If position-assignment fails or if, for any reason, we decide to not assign a position to a session, the position is set to 0 (which is treated as invalid position). During session_load() or if two sessions have the same VTnr, we may end up with two sessions with the same position (this shouldn't happen, but lets be fail-safe in case some other part of the stack fails). This case is dealt with gracefully by ignoring any session but the first session assigned to the position. Thus, session->pos is a hint, seat->positions[i] is the definite position-assignment. Always verify both match in case you need to modify them! Additionally, we introduce SwitchTo(unsigned int) on the seat-dbus-API. You can call it with any integer value != 0 and logind will try to switch to the request position. If you implement a compositor or any other session-controller, you simply watch for ctrl+alt+F1 to F12 and call SwitchTo(Fx). logind will figure a way out deal with this number. For convenience, we also introduce SwitchToNext/Previous(). It should be called on ctrl+alt+Left/Right (like the kernel-console used to support). Note that the public API (SwitchTo*()) is *not* bound to the underlying logic that is implemented now. We don't export "session-positions" on the dbus/C API! They are an implementation detail. Instead, the SwitchTo*() API is supposed to be a hint to let logind choose the session-switching logic. Any foreground session-controller is free to enumerate/order existing sessions according to their needs and call Session.Activate() manually. But the SwitchTo*() API provides a uniform behavior across session-controllers. Background: Session-switching keys depend on the active keymap. The XKB specification provides the XKB_KEY_XF86Switch_VT_1-12 key-symbols which have to be mapped by all keymaps to allow session-switching. It is usually bound to ctrl+alt+Fx but may be set differently. A compositor passes any keyboard input to XKB before passing it to clients. In case a key-press invokes the XKB_KEY_XF86Switch_VT_x action, the keypress is *not* forwarded to clients, but instead a session-switch is scheduled. This actually prevents us from handling these keys outside of the session. If an active compositor has a keymap with a different mapping of these keys, and logind itself tries to catch these combinations, we end up with the key-press sent to the compositor's clients *and* handled by logind. This is *bad* and we must avoid this. The only situation where a background process is allowed to handle key-presses is debugging and emergency-keys. In these cases, we don't care for keymap mismatches and accept the double-event. Another exception is unmapped keys like PowerOff/Suspend (even though this one is controversial).
2013-11-30 11:39:48 +01:00
Session **positions;
size_t position_count;
2011-05-25 00:55:58 +02:00
bool in_gc_queue:1;
2011-05-26 02:21:16 +02:00
bool started:1;
2011-05-25 00:55:58 +02:00
LIST_FIELDS(Seat, gc_queue);
2011-05-24 00:19:22 +02:00
};
int seat_new(Seat **ret, Manager *m, const char *id);
Seat* seat_free(Seat *s);
DEFINE_TRIVIAL_CLEANUP_FUNC(Seat *, seat_free);
2011-05-25 00:55:58 +02:00
2011-05-24 00:19:22 +02:00
int seat_save(Seat *s);
int seat_load(Seat *s);
2011-05-25 00:55:58 +02:00
int seat_apply_acls(Seat *s, Session *old_active);
int seat_set_active(Seat *s, Session *session);
int seat_switch_to(Seat *s, unsigned num);
logind: introduce session "positions" logind has no concept of session ordering. Sessions have a unique name, some attributes about the capabilities and that's already it. There is currently no stable+total order on sessions. If we use the logind API to switch between sessions, we are faced with an unordered list of sessions we have no clue of. This used to be no problem on seats with VTs or on seats with only a single active session. However, with the introduction of multi-session capability for seats without VTs, we need to find a way to order sessions in a stable way. This patch introduces session "positions". A position is a simple integer assigned to a session which is never changed implicitly (currently, we also don't change it explicitly, but that may be changed someday). For seats with VTs, we force the position to be the same as the VTnr. Without VTs, we simply find the lowest unassigned number and use it as position. If position-assignment fails or if, for any reason, we decide to not assign a position to a session, the position is set to 0 (which is treated as invalid position). During session_load() or if two sessions have the same VTnr, we may end up with two sessions with the same position (this shouldn't happen, but lets be fail-safe in case some other part of the stack fails). This case is dealt with gracefully by ignoring any session but the first session assigned to the position. Thus, session->pos is a hint, seat->positions[i] is the definite position-assignment. Always verify both match in case you need to modify them! Additionally, we introduce SwitchTo(unsigned int) on the seat-dbus-API. You can call it with any integer value != 0 and logind will try to switch to the request position. If you implement a compositor or any other session-controller, you simply watch for ctrl+alt+F1 to F12 and call SwitchTo(Fx). logind will figure a way out deal with this number. For convenience, we also introduce SwitchToNext/Previous(). It should be called on ctrl+alt+Left/Right (like the kernel-console used to support). Note that the public API (SwitchTo*()) is *not* bound to the underlying logic that is implemented now. We don't export "session-positions" on the dbus/C API! They are an implementation detail. Instead, the SwitchTo*() API is supposed to be a hint to let logind choose the session-switching logic. Any foreground session-controller is free to enumerate/order existing sessions according to their needs and call Session.Activate() manually. But the SwitchTo*() API provides a uniform behavior across session-controllers. Background: Session-switching keys depend on the active keymap. The XKB specification provides the XKB_KEY_XF86Switch_VT_1-12 key-symbols which have to be mapped by all keymaps to allow session-switching. It is usually bound to ctrl+alt+Fx but may be set differently. A compositor passes any keyboard input to XKB before passing it to clients. In case a key-press invokes the XKB_KEY_XF86Switch_VT_x action, the keypress is *not* forwarded to clients, but instead a session-switch is scheduled. This actually prevents us from handling these keys outside of the session. If an active compositor has a keymap with a different mapping of these keys, and logind itself tries to catch these combinations, we end up with the key-press sent to the compositor's clients *and* handled by logind. This is *bad* and we must avoid this. The only situation where a background process is allowed to handle key-presses is debugging and emergency-keys. In these cases, we don't care for keymap mismatches and accept the double-event. Another exception is unmapped keys like PowerOff/Suspend (even though this one is controversial).
2013-11-30 11:39:48 +01:00
int seat_switch_to_next(Seat *s);
int seat_switch_to_previous(Seat *s);
int seat_active_vt_changed(Seat *s, unsigned vtnr);
2011-05-25 00:55:58 +02:00
int seat_read_active_vt(Seat *s);
int seat_preallocate_vts(Seat *s);
2011-05-25 00:55:58 +02:00
2011-06-17 15:59:18 +02:00
int seat_attach_session(Seat *s, Session *session);
void seat_complete_switch(Seat *s);
logind: introduce session "positions" logind has no concept of session ordering. Sessions have a unique name, some attributes about the capabilities and that's already it. There is currently no stable+total order on sessions. If we use the logind API to switch between sessions, we are faced with an unordered list of sessions we have no clue of. This used to be no problem on seats with VTs or on seats with only a single active session. However, with the introduction of multi-session capability for seats without VTs, we need to find a way to order sessions in a stable way. This patch introduces session "positions". A position is a simple integer assigned to a session which is never changed implicitly (currently, we also don't change it explicitly, but that may be changed someday). For seats with VTs, we force the position to be the same as the VTnr. Without VTs, we simply find the lowest unassigned number and use it as position. If position-assignment fails or if, for any reason, we decide to not assign a position to a session, the position is set to 0 (which is treated as invalid position). During session_load() or if two sessions have the same VTnr, we may end up with two sessions with the same position (this shouldn't happen, but lets be fail-safe in case some other part of the stack fails). This case is dealt with gracefully by ignoring any session but the first session assigned to the position. Thus, session->pos is a hint, seat->positions[i] is the definite position-assignment. Always verify both match in case you need to modify them! Additionally, we introduce SwitchTo(unsigned int) on the seat-dbus-API. You can call it with any integer value != 0 and logind will try to switch to the request position. If you implement a compositor or any other session-controller, you simply watch for ctrl+alt+F1 to F12 and call SwitchTo(Fx). logind will figure a way out deal with this number. For convenience, we also introduce SwitchToNext/Previous(). It should be called on ctrl+alt+Left/Right (like the kernel-console used to support). Note that the public API (SwitchTo*()) is *not* bound to the underlying logic that is implemented now. We don't export "session-positions" on the dbus/C API! They are an implementation detail. Instead, the SwitchTo*() API is supposed to be a hint to let logind choose the session-switching logic. Any foreground session-controller is free to enumerate/order existing sessions according to their needs and call Session.Activate() manually. But the SwitchTo*() API provides a uniform behavior across session-controllers. Background: Session-switching keys depend on the active keymap. The XKB specification provides the XKB_KEY_XF86Switch_VT_1-12 key-symbols which have to be mapped by all keymaps to allow session-switching. It is usually bound to ctrl+alt+Fx but may be set differently. A compositor passes any keyboard input to XKB before passing it to clients. In case a key-press invokes the XKB_KEY_XF86Switch_VT_x action, the keypress is *not* forwarded to clients, but instead a session-switch is scheduled. This actually prevents us from handling these keys outside of the session. If an active compositor has a keymap with a different mapping of these keys, and logind itself tries to catch these combinations, we end up with the key-press sent to the compositor's clients *and* handled by logind. This is *bad* and we must avoid this. The only situation where a background process is allowed to handle key-presses is debugging and emergency-keys. In these cases, we don't care for keymap mismatches and accept the double-event. Another exception is unmapped keys like PowerOff/Suspend (even though this one is controversial).
2013-11-30 11:39:48 +01:00
void seat_evict_position(Seat *s, Session *session);
void seat_claim_position(Seat *s, Session *session, unsigned pos);
2011-06-17 15:59:18 +02:00
bool seat_has_vts(Seat *s);
bool seat_is_seat0(Seat *s);
bool seat_can_multi_session(Seat *s);
bool seat_can_tty(Seat *s);
bool seat_has_master_device(Seat *s);
bool seat_can_graphical(Seat *s);
2011-06-17 15:59:18 +02:00
int seat_get_idle_hint(Seat *s, dual_timestamp *t);
2011-05-25 00:55:58 +02:00
int seat_start(Seat *s);
int seat_stop(Seat *s, bool force);
int seat_stop_sessions(Seat *s, bool force);
2011-05-25 00:55:58 +02:00
bool seat_may_gc(Seat *s, bool drop_not_started);
2011-05-25 00:55:58 +02:00
void seat_add_to_gc_queue(Seat *s);
2011-05-26 02:21:16 +02:00
bool seat_name_is_valid(const char *name);
static inline bool SEAT_IS_SELF(const char *name) {
return isempty(name) || streq(name, "self");
}
static inline bool SEAT_IS_AUTO(const char *name) {
return streq_ptr(name, "auto");
}