GNOME Bugzilla – Bug 135337
Users should be able to specify Xserver config for a11y
Last modified: 2006-01-12 23:24:55 UTC
There are some Xserver extensions that are required for users with accessibility requirements. To turn such Xserver extensions on, it is necessary to pass the Xserver extra command line arguments. However, it is not desirable for these extensions to be turned on for all users - just users who need the features. A proposed solution would be to allow the specification of per-group Xserver commands in the gdm.conf file. This way, users who are in a particular group (say an accessibility group) would have the Xserver start with the proper arguments.
Thanks George, Brian for you help. Attaching a patch that solves this problem. This patch restarts X after the user is authenticated and before the session is started. But only if the user belongs to a particular group that is listed in the gdm.conf file and has some a11y features to be turned on. Please review the patch.
Created attachment 26717 [details] [review] Patch for this bug
George, can this fix go into gdm2? This is needed for accessibility, in order to turn on Xserver full-screen magnification for user's when they log in, based on their gid values.
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
Bala, can you add a testcase for this bug so that we can check if it is resolved? Thanks.
Frances, This patch has not yet gone into CVS. If you want to test this patch please follow the below steps 1. In gdm.conf file go to the end of the file and add something like the following [UserGroup-ally] XserverArg=+kb [UserGroup-ally1] XserverArg=+kb -accessx 2. You need to create groups called ally and ally1 3. Add users to the above groups 4. Login as user who belongs to group 'ally' 5. do ps -ef | grep X 6. X should have been started with +kb option 7. Logout and login as user belonging to group 'ally1' 8. do ps -ef | grep X 9. X should have been started with +kb and -accessx option George, it would of helpful if you could give comments or improvements for the attached patch. Thanks.
There is some discussion going on about whether it is a good idea to use groups in order to set user-specific Xserver configuration options. It has been pointed out that there are a limited number of groups available to be used in UNIX, and it might be better to use a different mechanism to determine if additional options should be used. Working on trying to get some closure on this.
Perhaps a better way to fix this would be to provide a menu choice so users can pick which Xserver config they want to use. One could be provided for a11y. So this could be solved by fixing bug #89421.
As mentioned in bug #89421, it is probably better to handle this in the *.desktop file, so an "a11y" session could be defined. To do this, the GDM *.desktop file would need to be extended to specify alternative xserver launching commands.
I disagree about the menu choice idea, because that would conflict with the end-user's gconf settings for assistive technologies, etc. if the user accidentally chose the wrong menu selection.
This still needs to happen automagically on a per-user (if not per-gid) basis.
In order for it to happen completely automagically, then it would be necessary to extend the gdm configuration file so that the xserver command can be specified in a per-user basis. Using UNIX groups would also work, but the concerns raised with adding a new group for each Xserver configuration probably mean that this approach isn't a good idea. Doing things this way will be a lot of work for the sysadmin to setup the gdm.conf file, especially if there are many users with a11y needs on a system. Allowing the Xserver choice to be set via a menu choice (either by picking a session or a new menu) is problematic since a user could accidently log in with the wrong settings and be unable to use the desktop fully. Does having an incorrect Xserver configuration break the user's experience so badly that they could not logout and log back in with the right settings if they ran into this problem? However, I don't think this is really such a showstopper since GDM's default session is already managed per-user. This is managed by the $HOME/.dmrc file, which is set up automatically by GDM. Anytime a user changes the session, GDM asks the user if they want this new session choice to be their default. If the user picks "Yes", then the $HOME/.dmrc file will specify that session. So any user who picks the "a11y" session as their default will always be logged in with this choice, as long as they don't mess with the menus and pick a different session by hand. In other words, users with a11y needs would have to change the menu setting once, on first login, but not each time. Also, the $HOME/.dmrc file could be setup for the user by a sysadmin before they first login if necessary so the user wouldn't have to mess with the menu on first login. If we wanted to make this bulletproof I guess we could also add a $HOME/.dmrc option which locks the user from being able to change their setting to anything else, preventing a user from accidently changing it. I think the *.desktop approach could work, and would probably be easier to implement, configure and use than the other approach of specifying uid/gid mappings to Xserver configurations in the GDM config files. But there might be other approaches I'm not thinking about, so ideas are welcome.
Brian asked: "Does having an incorrect Xserver configuration break the user's experience so badly that they could not logout and log back in with the right settings if they ran into this problem?" Possibly, for instance it could cause an app like gnopernicus to re-set its magnification source and target displays so that subsequent logins were messed up, too. However this may be an acceptable risk, given the fact that as you point out users would only need to select an appropriate session "once" in the most common scenarios. As a balance between risk and difficulty this might be the right answer.
also, for example, if you chose an x session without XKB or AccessX shortcuts enabled, then you might well be locked out and unable to try a second time.
I was going to do exactly what was suggested to implement +kb, etc, but Brian and I communited that hacking the code would be necessary. Bill, what about starting a new X session if a .xnitrc/.xsession was found in the user directory? I spent a little time beginning to learn the GDM code, but I was side tracked with other work. I suspect the functions are already there to control X sessions? I didn't get very far, but I was able to stop the current X session. I was having trouble sending GDM a new X session by executing "xinit"
*** This bug has been marked as a duplicate of 326771 ***