On Sun, Jan 03, 2010 at 01:08:07AM EST, Colin Guthrie wrote: > '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: > > [co...@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: > > [co...@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.
This sounds good, however one big problem is that speakup is actually kernel code, i.e its run as a kernel module, so it can get low level access to the tty devices to read the text. For the record, I am a vision impaired user, who uses a screen reader, and again for the record, this is an approach I am personally very much against. Instead, we need a daemon that will run as the idle user, and then through the hand-over stuff discussed in the rest of Colin's email, act appropriately. There are already user-space device nodes for reading the contents of the tty, and the BrlTTY Braille display daemon already uses these. BrlTTY already supports speech output, so it needs screen reader control via keyboard added, as well as working accross multiple user sessions etc. In short, what has happened here, is that the Linux desktop has evolved, and the accessibility software for people with blindness/vision impairement, has not. If such software wants to stay relevant, it has to evolve, or it will die. So yes we need consolekit to have idle user support, and then we need all the lower level accessibility software, eg for using Braille displays/speech output for the console, to also be improved to work system wide, and per user. I would be happy to do this work, if I had the time. :) Luke _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
