GNOME Bugzilla – Bug 122459
gnopernicus needs to work well with gdm
Last modified: 2004-12-22 21:47:04 UTC
gnopernicus needs to work reasonably well in the gdm login setting; that means working with read-only gconf keys (or, better yet, without gconf at all, using default values), and it needs to work without posting its gui.
Things that gnopernicus should do in order to work well with gdm: - command keys to turn on/off services (at a certain time the user might want to turn on or off a service. Even if s/he is at login time this might be usefull and it could have been atcheved with the UI. But, if we don't have a GUI, the user would have to launch gnopernicus with certain command line options. As the features are available, I find it useful to map them on certain keys on a layer, so the user can benefit of them) - speech to work at login time. At this moment is NOT working. (As I did not figure it out how to see the logs that are created by srcore at login time I have no idea why is this happening. Note: 1. gnome-terminal can not be launched at login time 2. srcore 2> log is not creating the log file These scenario is the expected one as it would cause security problems, but I would really nead to debug gnopernicus at login time. Brian: Do you have any idea how I could debug at login time? Marc: Do you have an idea why is speech not working at login time? ) - brlmonitor is a child of gnopi (UI) so in this current stage srcore can not benefit of its usage if the server is not launched. I created a script for this scenario, but this should be done in srcore: <snip> brlmonitor& srcore -o <snip> - decide how gconf settings will be approched: * to make it read only it requires a lot of work and I don't knoe if it worth it * what about being RW and at the end|begining of the session the entire gconf settings for gopernicus will be deleted (keys unset) - in case that we want to launch gnopernicus for diffrent gestures with diffrent command line options, the first instance of srcore must be terminated. I made a script for this, the script writes in gconf the "exit" key that normally is written by gnopi. * I still belive that we should make the settings and the read|write into gconf in a manner that there will be user-specific settings (I did not succeded in this, yet. I tryed gconftool-2 --config-source) The entire scenario that I have created is simulated through scripts, but srcore should implement it. I will attach the configuration files and the script that I've used.
Created attachment 21361 [details] The gestures that I've registred ->(dir_where_gdm_was_installed)/etc/gdm/modules
Created attachment 21362 [details] Script to launch srcore, but making sure that if there was previously ran, to terminate that process
Created attachment 21363 [details] Script that terminates srcore. This things were done by gnopernicus when the "Quit" button was pressed in UI
Created attachment 21364 [details] Script that launches brlmonitor server when srcore is launched with "-o " option (enable brlmonitor)
Created attachment 21365 [details] Script that unsets all the settings that were written in gdm's gconf-settings (for the case of RW gconf)
Created attachment 21366 [details] Script that simulates unsetting the keys by removing the setting directory. This can be ran as root.
Created attachment 21367 [details] gdm configuration file that launched srcore_unsetkeys_simulate as root at gdm's init time -> (dir)/etc/gdm/Init
I created a patch wich solve that, the braille monitor process can be started / stoped from srcore. The child will be created by the srcore instead of gnopi. Beside of this changes the patch added new layer commands, throught the user can activate deactivate the braille, the speech, the magnifier and the braille monitor. The layer is 10, and the following keys are associated K01 for braille, K02 for speech, K03 for magnifier, and K04 for braille monitor.
Created attachment 21384 [details] [review] Patch to activate / deactivate components from layers.
do you think it's important to allow brlmonitor at login time? Seems to be it's not necessary (except of course for debugging and demos).
I think to, that it is not so important to have a braille monitor at login time, but for architectual reason, and to have this feature in user time, and to have consistency for layer command to activate/deactivate with other components, I made this changes.
Okay, finally making some progress. I was having trouble with Gnopernicus not speaking properly on my machine, but upgrading to a more recent build seems to have corrected that problem. Then I was having trouble getting gdm2 to run programs via gestures. Upon further research, I discovered that it was only GNOME applications that were failing. Programs like xterm would launch fine. The problem turned out to be that on Solaris, the gdm user is given the HOME directory of / (root), where gdm does not have write authority. So when I run a GNOME program it can't create gconf files and the program will not start. Not exactly sure how we should fix the above problem. We could change the default HOME directory of the gdm user so it is a writable directory, or we could set the gdm users $HOME directory at runtime before launching the GUI programs, or perhaps use another mechanism for saving gdm configuration data in a specified location. So now I am back at the point where I am able to launch GOK, gnopernicus with magnification and braille monitor, but speech is still not working. I notice that changing the ownership of /dev/audio and /dev/audioctrl to the gdm user does not fix the problem as I was hoping. When I create a gesture to launch an xterm and try running Gnopernicus it says "Speech initialization failed". When I try and run test-speech, I see the following: --test-speech output begin-- ./test-speech 1: OAFIID:GNOME_Speech_SynthesisDriver_FreeTTS:proto0.3 2. OAFIID:GNOME_Speech_SynthesisDriver_Festival:proto0.3 Select a server: 1 Attempting to activate OAFIID:GNOME_Speech_SynthesisDriver_FreeTTS:proto0.3 No server selected. --test-speech output end-- I see the same "No server selected" MESSAGE if I select server #2 as well.
Hmmm. I notice the same behavior happens if you simply su to the root or gdm user and then try to run test-speech. It fails in the same way. chmod'ing /dev/audio and /dev/audioctl to 644 doesn't seem to make any difference, nor does chown'ing /dev/audio and /dev/audioctl to the user who is trying to run test-audio. Any tips on how to get test-speech to run as another user, such as root?
Created attachment 27889 [details] [review] proposed patch
There is still some work to be done in the speech module so probably this patch shouldn't be on CVS yet.
This bug is now a gnopernicus issue. I will reasign it.
Created attachment 27990 [details] [review] proposed patch This patch should be ok but shouldn't be commited to CVS until is actualy tested with gdm.
Managed to start gnopernicus with gdm. Magnifier and Braille monitor work, Speech doesn't start.
The only way I managed to get speech working in gdm was to change in gdm.conf the user and group from user=gdm group=gdm to user=dragan group=users. In this case everything worked ok. The settings in gnopernicus remained after re-starting gnopernicus.
Since everything seems to work I will apply the patch in CVS.
I'm confused here. We cannot change the gdm user to be anything other than 'gdm/gdm' on a real system. We had a bunch of trouble with speech at 'gdm time', but I thought those were resolved. Perhaps we need a separate bug for this (and perhaps this code can go back), but we aren't finished until the speech issue is resolved. Dragan, two questions: (1) are you certain that with your patch and the user/group change, no writes are happening to gconf? (2) with the user/group remaining gdm/gdm, and without speech, does Gnopernicus work property (e.g. Braille only, or Braille Monitor)?
Hi Peter, You are right we cannot change the gdm user. I'll keep trying to make the speech work with gdm/gdm user and group . For question 2: -braille & braille monitor & magnifier work ok -strange thing :the settings remain changed even after I restart gnopernicus -I tried this for braille, braille monitor & magnifier For question 1: -the functions that write the settings to gconf are called when the settings are changed but they should fail and the current values are kept internaly in the structures. -I'm not shure that a write to gconf doesn't happen since the settings remain in gnopernicus after restarting. I'll keep investigating this.
Before we close this bug we need to understand why/whether the changes are being persisted (since we don't want them to persist in the gdm case), and ensure that they don't persist.
The changes made gnopernicus settings when it's running with gdm, are kept in / var/lib/gdm/.gconf/apps/gnopernicus
I agree with Bill about not closing this bug yet. My tests show that the changes do persist after restarting gdm . I don't know why the changes persist.
Dragan/all: If you followed some directions (circulated elsewhere I think) about how to configure gdm for accessibility, they may have included creating a home directory for user "gdm". In actual use in a normal deployment, this is not desirable. So you may need to check and make sure gdm doesn't have a home directory. If user or group gdm has a home directory, we may need to remove it in order to prevent this behavior and in order to test the "preferred" configuration. Giving gdm a home directory is not the preferred solution since it can raise some security concerns, and many sysadmins will not want to do this.
after discussion with Marney and Peter, etc., escalating priority since this is critical functionality.
Usually the gdm user has a home directory (/var/lib/gdm). To remove if, you have to delete the home path for gdm user from /etc/passwd file. Also, in order to start speech, the gdm user must be member of audio group. This can be done by editing /etc/group and adding gdm on the line for audio group. After all those "system tunning" gnopernicus expects to read some information from gconf.
I can't find the --login option in srcore's commandline parameters. I thought we agreed that there should be one? Seems it's needed to keep from changing gconf params during login (otherwise the only way srcore/gnop knows anything is different is if there's no $HOME dir).... If so it needs to go in right away, since our UI is supposed to be stable now.
Created attachment 29353 [details] [review] additional patch This patch enables srcore to be controled via Command Layers whithout writing and reading from gconf. This was necesary mainly for the magnifier. To do this "--login" option must be specified to srcore command line. This patch also contains a few improvements, assertion checking & stuff.
Patch comited to CVS Head
This bug is fixed. Now gnopernicus works well with gdm with or without home directory (for gdm user) and issue about gdm user being member of audio group is solved. The remaining issue is subject of bug 144920.
I am not sure we should have closed this bug without the ability to verify it...
The bug was cheched from a terminal at login time.
ok - but doesn't that require that the gdm user have a login shell?
This bug depends on bug 144920.
Closing because bug 144920 was fixed.