I'm using sway both for greeter with gtkgreet and as my wm. I have VT1 and VT6 configured to run sway/gtkgreet. On boot i'm being dropped to VT1 by default where sway/gtkgreet starts successfully. Then I login on VT1, greetd started sway/gtkgreet exists, and my user WM sway starts. Now if I press Alt+Ctrl+f6 to go to VT6, greetd there will attempt to start another sway/gtkgreet on waitactive. Second sway/gtkgreet attempts to open a number of devices which are still acquired by sway/WM on VT1 and fails with:

00:00:00.004 [DEBUG] [sway/server.c:47] Preparing Wayland server initialization
00:00:00.004 [ERROR] [wlr] [libseat] [libseat/backend/seatd.c:301] Could not poll connection: Broken pipe
00:00:00.004 [INFO] [wlr] [libseat] [libseat/libseat.c:70] Backend 'seatd' failed to open seat, skipping

Because seatd fails with:

00:28:35.558 [INFO] [seatd/server.c:140] New client connected (pid: 2720, uid: 0, gid: 999)
00:28:35.558 [ERROR] [seatd/seat.c:152] Could not add client: seat is VT-bound and has an active client
00:28:35.558 [ERROR] [seatd/client.c:149] Could not add client to target seat: Device or resource busy

After sway/WM on VT1 finally completes cleanup and gets disabled:

00:28:36.126 [INFO] [seatd/seat.c:571] Disabled client 1 on seat0

Second sway/gtkgreet successfully starts on VT6.

After discussion on IRC, we concluded that most likely some synchronization is required. If new client arriving while another client is in progress of disabling, newly arrived client could wait until client being disabled is done.

Another (also arguably better) way could be delaying greetd worker until designated terminal is active.

Probably in greetd/src/server.rs right after:

    let term_mode = get_tty(&config)?;

it could be possible to wait for term_mode.vt to become active before proceeding using any of:

• ioctl: VT_WAITACTIVE
• inotify: /sys/devices/virtual/tty/tty0/active
• or similar

Then if user never switches to specific tty, greetd won't start worker and greeter for it.

greetd/src/server.rs on line 27 calls

term.vt_setactivate(*vt)?;

However TerminalMode::Terminal constructed with hardcoded switch: true or switch: false.

When greetd is started with agreety for multiple terminals, each greetd results in calling term.vt_setactivate which causes:

• flickering from terminal to terminal
• active terminal remains the last one greetd process is started for, then user should select Ctrl+Alt+f1 if first terminal is needed for login

I would suggest to add switch option in ConfigTerminal, and pass it to TerminalMode::Terminal, so that primary terminal could be configured to call term.vt_setactivate and others not.

it is not hardcoded, you can pass -c/--config flag with path to config