Nicolas: > On Mon, Dec 08, 2008 at 03:27:49PM -0600, Brian Cameron wrote: >> login, they get the audio device. Then you can use VT switching in GDM >> to start up a second graphical login. If this user needs text-to-speech, >> they are out of luck since they can't access the audio device from their >> user session regardless if they can log in. At any rate, VT is not yet >> enabled in the Xserver or GDM, so there really isn't an issue that needs >> to be addressed until this is integrated and working in Solaris. > > Well, shouldn't this mean that /dev/audio should get virtuallized so > that it's as /dev/null when the console is switched to a different VT, > so only the current VT ever has access to the real /dev/audio? > > Is there a shortcomming in VT here?
I guess it depends on how you think VT should work. My understanding is that VT works on a first-come-first-serve basis, so the first user who calls logindevperm interfaces gets permission. While it might seem nicer for the last user to get the device, this is much harder to manage. Making it work the other way would require logindevperm to be enhanced. I believe this is because logindevperm only has interfaces to indicate a user has logged in or out, and does not support any way to inform logindevperm that a user switch has happened. Also, I think it gets complicated to manage if the first user has programs running which are using the audio device, or other devices managed by logindevperm. How to manage unconnecting them when a VT switch happens, and then reconnecting them when switching back would be complicated and probably error-prone. At any rate, I think it would be a pretty significant enhancement to the existing interfaces to support this sort of behavior. If you are interested, you can discuss this further with the VT team if you want to make suggestions about how this should all work. [EMAIL PROTECTED] is the engineer working on VT, and would be the right person to talk to. >> Console login also does use logindevperm, so you could also have this >> problem if a user logged into a text console, then started GDM. Though >> this would be an odd usage of the system. If a user were to do this, >> they shouldn't be surprised if it doesn't work properly. > > I would be! If you log into the console first, then it calls logindevperm interfaces first and wins. Any graphical logins would not get permission, unless (of course) you logged into the same user as you used when logging into the console. At any rate, now that you know, you will not be surprised. :) >> Perhaps I should explain the history of this a bit, just so you understand >> how the code has evolved. In Solaris 10, GDM used logindevperm to give the >> ... > > I didn't realize that we had A11Y support in S10's GDM! I thought that > was one of the problems with it. How do you configure A11Y for GDM? I > would really like to enable sticky keys at the GDM screen. When I have been talking about to a11y in GDM, I have been referring to the ability to start AT programs such as orca or GOK. Xserver a11y features like sticky keys should "just work" if you enable them via keyboard shortcuts. I believe hitting the Shift key five times in a row enables Sticky Keys. I am not sure if this keyboard shortcut is available by default or not in GDM. You might need to setup your Xserver configuration or the Xserver arguments used when GDM starts the Xserver in the GDM configuration to make this work. There is probably also some Xserver interfaces you could use to configure it to just always be on by default, though I am not sure how to do that. You would need to refer to the Xserver documentation. >> The login GUI is run with limited privilege. > > Ah, OK. > > So methinks there needs to at least be a comment in logindevperm code to > guard against someone causing it to clobber GDM's ACL entry. The ARC > might care to know too; ask a member. Thanks, I overlooked bringing this up to ARC. I will make sure that the GDM usage of these interfaces is ARC'ed before VT is enabled in the Solaris Xserver and GDM. This really only becomes something to care about after that happens. I do appreciate you helping me to make sure we integrate all of this properly. Brian _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
