'Twas brillig, and Tanu Kaskinen at 02/01/10 05:59 did gyre and gimble: > So that's how I see it should work. I'm not very confident when speaking > about consolekit and boot/login processes, so I have to hope that the > system I described isn't too different from how things work in reality. I think I agree more or less, but with perhaps a few caveats/clarifications. 1. I think the "anybody" user is a valid concept. I'd personally call it the "idle" or "inactive" user as homage to the active denomination in consolekit already. To run some practical tests, if you run: [colin at jimmy ~]$ ck-list-sessions Session1: unix-user = '603' realname = 'Colin Guthrie' seat = 'Seat1' session-type = '' active = TRUE x11-display = ':0' x11-display-device = '/dev/tty7' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2009-12-30T09:40:14.334448Z' login-session-id = '4294967295' you can see that I am the "active" user currently. If however I run the following and then switch to the login window on tty1: [colin at jimmy ~]$ sleep 3; ck-list-sessions Session1: unix-user = '603' realname = 'Colin Guthrie' seat = 'Seat1' session-type = '' active = FALSE x11-display = ':0' x11-display-device = '/dev/tty7' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2009-12-30T09:40:14.334448Z' login-session-id = '4294967295' Here we see that no user is currently "active". In this mode no user is active on my system - i.e. it's "idle". Now lets think about permissions. Some folks have recently mentioned the "audio" group. This is a relic and should not be used or considered for controlling access to audio hardware. The real way forward is the interaction between udev and console kit applying ACLs for the appropriate users. Now in this case we really need to define a user on the system who is "idle". Both udev and console-kit probably need to be aware of this concept and write the appropriate ACLs to the sound hardware for the "idle" user, removing them when a real user logs in (and in this case "gdm" should be considered a "real" user. In this case the boot scenario (permissions wise) would be as follows: 1. Turn on (this will rarely change and I predict will remain the first step for many years :p) 2. udev kicks in. 3. system dbus starts 4. consolekit starts and due to no active users instructs udev to write the idle user to the audio device node ACLs (I'm not 100% sure whether udev drives console-kit or the other way round, so someone more familiar than me with this can hopefully clarify) 5. Some special handling in the boot process will launch speakupd as the idle user (I think this is appropriate - there should not (IMO) be a central daemon for sepakupd - it should be launched when needed). I'm not specifically sure if it is the "boot up" process per-se or the "system becomes idle" case that really should be responsible for starting speakupd... My gut feeling is that console-kit should be aware of "idle" status and have a set of hooks that can be run when this happens. These hooks could then be used to start speakupd as the idle user). At this stage the idle user can now start talking about what is going on with the boot. 6. X is launched and GDM (or equiv) is started, console-kit will now realise there is an active session started for the gdm user and remove the ACLs on the sound device. The idle user's speakupd can die as can it's PA instance. GDM user will start it's own speakupd and PA process. 7. If at this stage the user logs in graphically then the same thing as idle->gdm happens. The gdm user's PA and speakupd process dies and the real user's one will kick in. 7b. Now if the user switches to tty1 (whether at gdm login screen or after logging in - the concept is the same), console-kit will notice the system has become idle and apply the appropriate ACLs, due the "idle hooks" mentioned in 5 above, speakupd/PA will be launched and the login prompt can be described audibly. Once logging in the user becomes active again, so the idle user is killed off as before and can hand over to the real user. Thinking about it, I think that consolekit itself is really what should be responsible for starting speakupd (which will in turn start pulseaudio if appropriate). I think that some kind of "system becomes idle" and "user becomes active" hooks would provide the necessary framework into which speakupd could integrate. The concepts of "starting a service" are starting to erode these days with more and more things being triggered from udev, so the general migration to this approach (i.e. making speakupd "serviceless") seems to be followed with the above suggestion too. Also on a system shared by both blind and sighted users there does not need to be any special support for detecting the current user and either giving prompts or not. If speakupd is running it is running, it doesn't need to be any cleverer than that. If I am correct with the above plan all that really needs to be modified is consolekit. Perhaps someone can have a bit of a think about this and see if it makes sense and then perhaps discuss with the consolekit guys? HTHs Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
