|
Bugzilla – Full Text Bug Listing |
| Summary: | login not possible when a tablet is used | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 10.3 | Reporter: | Marco Michna <mmichna> |
| Component: | GNOME | Assignee: | Rodrigo Moya <rodrigo> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Critical | ||
| Priority: | P5 - None | CC: | coolo, dg001, federico, hpj, kde-maintainers, rhorstkoetter, sndirsch, werner |
| Version: | Beta 2 | Flags: | coolo:
SHIP_STOPPER-
|
| Target Milestone: | --- | ||
| Hardware: | i586 | ||
| OS: | openSUSE 10.3 | ||
| Whiteboard: | gnome-function-does-not-work, gnome-wrong-out-of-the-box | ||
| Found By: | Component Test | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Bug Depends on: | 331577, 334446, 337428 | ||
| Bug Blocks: | |||
| Attachments: |
gnome-screensaver-xvkbd-on-lock.patch
Newest version of the patch create-notify.diff Packages with the fix Lang package with the fix New patch, with xvkbd showing correctly and being killed when unlocked New version of the patch with Federico's suggestions GDM patch to be approved by Hans Petter the log files from gnome-screensaver the log files from gnome-screensaver |
||
|
Description
Marco Michna
2007-08-24 15:35:38 UTC
I fixed a bug recently on gnome-screensaver that should fix this, but given the reporter mentions GDM also, not sure if it's something else. Holger, any idea? What was the bug you fixed related to? Anyway, I have no idea ;-) Danny? The fix was related to uninitialized XWindowAtrributes structures on the new code for the xvkbd integration. Not sure if GDM uses a similar code (I copied it from kscreensaver IIRC). Marco, could you please try these packages: http://w3.suse.de/~rodrigo/gnome-screensaver-2.19.7-4.i586.rpm http://w3.suse.de/~rodrigo/gnome-screensaver-lang-2.19.7-4.i586.rpm of course, this only fixes the screensaver part, so please test that. If it fixes, we might need a similar fix for GDM. No it does not work - now it even does not display the virtual keyboard (xvkbd). Marco, please test these packages: http://w3.suse.de/~rodrigo/gnome-screensaver-2.20.0-2.i586.rpm http://w3.suse.de/~rodrigo/gnome-screensaver-lang-2.20.0-2.i586.rpm It still does not display the virtual keyboard. hmm, this worked for me the other day, but now I see it just works intermitently. Created attachment 175991 [details]
gnome-screensaver-xvkbd-on-lock.patch
Rodrigo, this is the patch which you asked me to review but I dropped the ball on that --- sorry :(
Is this the latest version of the patch, or do you want me to review a newer one?
Adding myself to the CC list. No, that's not the last one I sent you. Attaching the new one. It's still not showing the xvkbd window, so could you please have a look to see what's missing? Created attachment 176123 [details]
Newest version of the patch
Created attachment 176214 [details]
create-notify.diff
Incremental patch on top of Rodrigo's. With this, the xvkbd window appears properly. However, it doesn't exit when the screen gets unlocked. Rodrigo, are you familiar with that part of the code?
Created attachment 176294 [details]
Packages with the fix
Created attachment 176295 [details]
Lang package with the fix
Created attachment 176296 [details]
New patch, with xvkbd showing correctly and being killed when unlocked
Marco, please test attached packages, they work perfectly for me now. Federico, please review the last attached patch package gnome-screensaver-2.20.0-4 (which is newer than gnome-screensaver-2.20.0-1) is already installed I will try with force now. But it isnt good to be not in sync with the build. This only works if you have kdm as loginmanager. When you use gdm then there is no virtual keyboard. These packages only fix the gnome-screensaver part. Does that work for you when you install them? Getting back when screensaver is running works. (In reply to comment #17 from Rodrigo Moya) > Federico, please review the last attached patch I'd compress the various instances of + if (xvkbd_running) + kill (xvkbd_pid, 9); into a helper function. Also, the part where you invoke hal-find-by-property is commented out... should that be uncommented? I don't like using system() there. Can it simply use g_spawn_sync() for safety? yes, the part commented should be uncommented, and is on the autobuild dir I'm going to submit, just created the packages with that commented out to make it easier to test. Will change it to use g_spawn_sync (as soon as I get access to the internal network) Created attachment 176628 [details]
New version of the patch with Federico's suggestions
bug 149957 seems to be the original for gdm. CC'ing Stefan Dirsch since he seems to have done the original work. I'm not sure how I can help here. Stefan, the GDM part of the bug is what is still "broken", Marco can't see the xvkbd window at all when login in. Marco, this is still the case right? The xvkbd part is in /etc/X11/xdm/Xsetup, which is part of xorg-x11, and which you added, according to bug #149957. The code is: # # Check if the machine is a TabletPC and start # xvkbd in xdm do be able to input username and password # $halporp --key system.formfactor.subtype --string tabletpc if test $? -eq 0 -a -x $xvkbd ; then # Bug 238604 if grep -q DISPLAYMANAGER_AUTOLOGIN="" /etc/sysconfig/displaymanager; then # Bug 149957 ( declare -i t=100 while test $((t--)) -gt 0 ; do case "$(xwininfo -root -children)" in *greet*|xlogin) break ;; esac sleep 0.1 done HOME=/root exec $xvkbd -compact -geometry -0-0 -xdm ) & echo $! > /var/run/xvkbd.pid fi fi Marco, you don't have autologin enabled, right? Yes this is still the case and yes, I don't have autologin enabled because I have several users on this laptop (main user and a test user). We should probably get the output of hal-find-by-property --key system.formfactor.subtype --string tabletpc from you Marco. Also, with gdm are you using the standard "greeter" or the old style login window? (In reply to comment #24 from Rodrigo Moya) > Created an attachment (id=176628) [details] > New version of the patch with Federico's suggestions Looks good! /org/freedesktop/Hal/devices/computer I'm using the default greeter and didn't change anything there. Marco, is xvkbd running at all? (that is, 'ps aux | grep xvkdb' shows anything?) or is it just not showing? Yes - sure it is running. --8<-- tux 3736 0.0 0.2 4232 2180 ? S 12:40 0:00 xvkbd -->8-- Ok, so what did you do to set the tablet up? I am experimenting with some setups, and in some cases, the process is not even run. I don't see what the setup of the tablet has to do with the xvkbd not coming up with gdm - the same setup works perfectly with KDE and kdm.
But anyway ...
- start YaST2
- Hardware
- Graphics Card and Monitor
- Tablet
- Activate this Tablet
- FINEPOINT
- GATEWAY (FPI2004)
and thats all.
Stefan, we are not seeing Xsetup being ran with GDM, any idea what might be going on? It appears to be a gdm issue. Seems the cause for not having Xsetup run is gdm's fault, because of a patch that got rediffed and lost part of the fixes we had. The patch is: https://api.opensuse.org/source/GNOME:STABLE/gdm/gdm-xdm-sessions.patch and here's the new version of the patch: https://api.opensuse.org/source/home:rodrigomoya/gdm/gdm-xdm-sessions.patch Hans Petter, can you have a look and see if something else might be affected by the missing part of the patch? Marco, test packages including the new version of the patch are (or will be soon, as soon as the build service builds them) at: http://download.opensuse.org/repositories/home:/rodrigomoya/openSUSE_10.3/ The new packages help start xvkbd consistently for me at least however xvkbd is not brought to the front of the greeter screen. I can see it come up and then be overwritten by a the gdm artwork. Using just the original line in Xsetup: ( sleep 1; HOME=/root exec $xvkbd -compact -geometry -0-0 ) & echo $! > /var/run/xvkbd.pid Worked and so does adding a: ( sleep 1; declare -i t=100 Its not clear to me why this changed from the original script in bug 149957 or why exactly this works - my guess is that gdm sets the root window twice for some reason once when starting up and once for the greeter pixmap or overlays the greeter pixmap on the root window. The /etc/X11/xdm/Xsetup script needs updating as well though as it uses a gnome2root of /opt/gnome/sbin instead of /usr/sbin on 10.3. > Its not clear to me why this changed from the original script in bug 149957 It makes sure that xvkbd is *started* after the greeter of the display manager is available. See Bug #149957, comment #27 and the following. > The /etc/X11/xdm/Xsetup script needs updating as well though as it uses a > gnome2root of /opt/gnome/sbin instead of /usr/sbin on 10.3. Indeed. So our gdm on 10.3 looked rather ugly and nobody noticed it so far. I will fix this for STABLE. xorg-x11 package submitted for STABLE. ------------------------------------------------------------------- Wed Nov 7 06:56:24 CET 2007 - sndirsch@suse.de - /etc/X11/xdm/Xsetup: * /opt/gnome/sbin/gdm --> /usr/sbin/gdm * gnome-window-decorator --> gtk-window-decorator Rodrigo: Yes, it looks like missing those hunks could cause a wide range of ill effects, for instance on user device permissions and DPMS screensaving in gdm. Yes, so it's the -xdm argument that makes it not work. Without that, it works great for me. Rodrigo, what's different with "-xdm"? Don't know, it started working when I removed that argument, but now it didn't work again, so added -always-on-top and now it seems to work every time. So HOME=/root exec $xvkbd -compact -geometry -0-0 -xdm -always-on-top Hans Petter, we found also the /etc/gdm/PreSession/Default runs a xsetroot command. Is this ok? Could this be the cause of the problem? Ok. I thought "-xdm" would be a gdm option. Please let me know in case I should add the -always-on-top option to xvkbd in Xsetup script. Stefan, it works all the time for me, except for the fact that you have to press the 'Focus' button on xvkbd to get the focus to the GDM entry for username/password. I guess the focus should be there by default, right? Let's wait for Hans Petter to comment on the PreSession/Default file, and we'll see if we need to add that -always-on-top. Because, that shouldn't affect KDM/XDM, right? Well at least for the greeter it shouldn't hurt. Not sure if it should stay on top afterwards. It gets killed in /etc/X11/xdm/Xstartup, so it shouldn't be kept around, right? Right, so this option should be safe. with KDM, it works, without having to press the 'Focus' button on xvkbd. It doesnt get killed though, so it seems KDM is not running the Xstartup file? Honestly I have no idea which files in /etc/X11/xdm are still used by kdm. :-( CC'ing KDE team on #52 and #53. (In reply to comment #52 from Rodrigo Moya) > with KDM, it works, without having to press the 'Focus' button on xvkbd. It I wonder if this is because in the gdm case xvkbd comes up before the user name entry is available and focussed. Maybe it works better with the sleep 1 (or 2 or 3) hack again? Maybe, but maybe gdm can also be fixed to provide "gdmgreeter", when asked via "xwininfo -root -children", *only* when the greeter has already been started. Obviously this is what xdm/kdm can properly do ... The real question might be why is background color getting set against the root window just before the greeter appears. I don't know if thats in one of these scripts or in the GDM code itself. This is in Xsetup as well. It's done because gnome2root is still set to /opt/gnome/sbin on 10.3.
[...]
gnome2root=/opt/gnome/sbin
gdmpid=/var/run/gdm.pid
gdm=no
test -x ${gnome2root}/gdm && \
/sbin/checkproc -p $gdmpid ${gnome2root}/gdm &> /dev/null && gdm=yes
#
# Handle background:
# First kdm/gdm choise, then xdm/user choise and
# if no choise is given use the system defaults.
#
if test "$kdm" = "yes" -o "$gdm" = "yes" ; then
: # $xsetroot -solid '#738dc6'
elif test -s ${background}.gz -a -x $xpmroot ; then
$xpmroot ${background}.gz
elif test -s ${background} -a -x $xpmroot ; then
$xpmroot $background
elif test -x $backprg ; then
$backprg
else
$xsetroot -gray
fi
[...]
I have that test fixed here and it still seems to be happening. It looks like gdm, it appears to be doing this to hide the stipple. That seems like an antiquated reason these days. Its probably patchable, but of course adds a little risk (comment also implies its used for Xinemera - not sure why exactly). The current upstream code (will be gdm 2.22) seems to have dumped this ugliness so it should be sorted for 11.0 soonish. I've tried several things on the script, but can't get the entry to get the focus properly, and yes, the background seems to be set before you actually see the GDM greeter window, with the /opt/gnome->/usr fix in. Hans Petter, what do you think about what Stefan says in comment #56? Also, the focus problem doesn't seem to be because the xvkbd window is open before the greeter is actually started, or doesn't seem so, since I added a sleep (up to 10) to actually start xvkbd after the greeter is up and running, and the problem persists I think it's doable. Stefan: How exactly should I set the information on the windows so the information is exposed to the script the right way? Rodrigo: When this is ready, it should probably be submitted together with the GDM changes for bug 332498. hpj: It's my understanding that gdm already sets "gdmgreeter", but apparently not at the right time. Ok, but how is it set? (Would that even fix the bug, though? From what Rodrigo says, it sounds like it wouldn't). I don't know anything about gdm. xdm uses "xlogin" instead of "gdmgreeter". It's the application_name.
./greeter/greet.c: dpy = XtOpenDisplay (context,
d->name, "xlogin", "Xlogin", NULL, 0,
See manual page of XtOpenDisplay for more details.
I can't find neither where this is set, the greeter does not use XtOpenDisplay nor XOpenDisplay (just gdk/gtk_init), and it doesn't seem to have any instance of "gdmgreeter" at all. So not sure where to fix it, Hans Petter? The focus bug is present also in SLED10, so JP agrees on shipping these fixes and leave the focus problem for OS 11. So, to sum up, we need a SWAMP ID for these fixes to get into 10.3: * gnome-screensaver fix (https://bugzilla.novell.com/attachment.cgi?id=176628): approved by Federico and confirmed to work by Marco * GDM patch: needs approval by Hans Petter, attaching after this comment * xorg-x11 fix, with the /opt/gnome -> /usr/bin, gnome-window-decorator->gtk-window-decorator and the addition of the -always-on-top argument to xvkbd. Stefan, would you take care of this part, or should I? We also need to submit all of these to STABLE, which I'll start doing (gnome-screensaver part). Hans Petter, let me know how to co-ordinate the other GDM fixes you have. Created attachment 182807 [details]
GDM patch to be approved by Hans Petter
gnome-screensaver part submitted to STABLE Rodrigo, the information that gdm uses "gdmgreeter" I got by Werner. Maybe this information is no longer up-to-date. I didn't verify it. Why is it that important to fix these issue for 10.3? Do we have so many tablet pc users, who use gdm? Obviously nobody noticed it during the alphas/bets. I hate writing patchinfo files. Sure I'll add the -always-on-top option for STABLE. >Sure I'll add the -always-on-top option for STABLE.
done.
Stefan, what about 10.3 submission? Since we need to co-ordinate the 3 submissions, I can attach the patch and once you approve it I can submit it myself. (In reply to comment #70 from Stefan Dirsch) > Rodrigo, the information that gdm uses "gdmgreeter" I got by Werner. Maybe this > information is no longer up-to-date. I didn't verify it. > > Why is it that important to fix these issue for 10.3? Do we have so many tablet > pc users, who use gdm? Obviously nobody noticed it during the alphas/bets. I > hate writing patchinfo files. Sure I'll add the -always-on-top option for > STABLE. Well, Marco noticed it, this was a mandatory feature, it improves things for non-tablets as well and historically we have lots of 10.3 upgrades after more than just the first month of release. We can write the patchinfo for you Stefan as we can bundle it with the gnome-screensaver fix in one swamp id. Rodrigo, feel free to do so. The script is in xorg-x11 package, in xdm.tar.bz2. Only xorg-x11 package needs to be updated. Please keep me up-to-date. xorg-x11 package submitted for 10.3: ------------------------------------------------------------------- Sat Nov 10 05:20:16 CET 2007 - sndirsch@suse.de - /etc/X11/xdm/Xsetup: * /opt/gnome/sbin/gdm --> /usr/sbin/gdm (Bug #304399) * gnome-window-decorator --> gtk-window-decorator (Bug #304399) * added -always-on-top option to xvkbd call (Bug #304399) It might be possible to just add xorg-x11 to the package list of your patchinfo file, you wanted to submit anyway. Thanks Stefan for submitting it. And yes, I'll include your xorg-x11 submission in the patchinfo I submit. Although, you haven't included the SWAMP-ID in your submission, don't you need to? Anyway, still waiting for Hans Petter to review the patch. As soon as he does, I'll do the full submission along with the other GDM fixes Hans Petter has ready. Bugzilla entry should be enough to get the package checked in once it is clear that a maintenance update will be done. SWAMPID is for patchinfo file. Ok, I thought the SWAMP-ID had to be included in the package's changelog Stefan: (comments #52,#53) KDM should run Xsetup and Xstartup just like XDM does (and it works that way on my machine). grep etc/X11 /mounts/dist/unpacked/i386.full/opt/kde3/share/config/kdm/kdmrc # Default is "/etc/X11/xdm/Xaccess" #Xaccess=/etc/X11/xdm/Xaccess # Default is "/etc/X11/xdm/Xwilling" # Default is "/etc/X11/xdm/Xsetup" # Default is "/etc/X11/xdm/Xstartup" # Default is "/etc/X11/xdm/Xreset" # Default is "/etc/X11/xdm/Xsession" # Default is "/etc/X11/sessions,/opt/kde3/share/apps/kdm/sessions,/usr/share/xsessions" gnome-screensaver submitted also then. Hans Petter, let us know when you are ready for the GDM submissions and we'll ask for the SWAMP-ID and (me) create the patchinfo The updated patch looks good. Ok, so all packages are now submitted (included the fix for bug #337428), so Anja, we need a SWAMP-ID Bug 341113 seems to only appear on factory but we should solve it before shipping the update in this bug of gnome-screensaver so we have some confidence in the fix. Marco, I guess you have been running with my packages all this time. Did you see anything similar to bug #341113? It seems to happen now for me on both 10.3 and FACTORY I don't understand the point of the question in #88 if you can dupe the problem and bug 341113 has logs and the packages attached for testing in this bug do not seem to have the latest version of the patch from #24. It seems like the CreateNotify addition could be problematic. No swamp id required from Anja until this is solved. JP, I was trying to see in what version of the patch the problem showed up, since I didn't see it myself (I've been running with the last patch since I posted it here). And I found it is in the g_spawn_command_line_sync call, getting it back to use system makes it work as before, so there might be something bad in that glib call, which was not when I tested the last change, but can't see any changes related to this in the glib package, so not sure what's up. Re-submitted with the g_spawn_command_line_sync->system change. Attaching new packages in a little bit to make sure everything works as expected. Marco, please test them New packages are at: http://www.gnome.org/~rodrigo/rpms/304399/ Marco, please test them Fix confirmed to work on FACTORY also by a couple of people now Just tried the new packages and now it shows a very strange behavior. Most of the time the virtual keyboard is there but the position of the login window changes. Sometimes its a little bit to the left and sometimes it is on the right border of the screen. When it is on the right border then it also is not shown completely - the left part is cut off (begins at the U from the Switch User button). And BTW - when the virtual keyboard is shown then it is possible to login via the tablet. This is really weird, the last packages I posted are identical to the ones Marco has been running since he confirmed the fix. Marco, could you please get debugging info as stated in http://en.opensuse.org/GNOME/Submitting_Bugs#GNOME_Screensaver ? When I do that then I can't lock the screen and it also does not lock the screen after 10 min. So, this only happens with the new packages I built, right? If you install these: https://bugzilla.novell.com/attachment.cgi?id=176294 https://bugzilla.novell.com/attachment.cgi?id=176295 everything works as expected, right? Also, when following the instructions in http://en.opensuse.org/GNOME/Submitting_Bugs#GNOME_Screensaver, does starting gnome-screensaver on the command line raises any error message or warning? It sounds like it didn't start correctly, so could you please paste here the output of those commands to see why you don't get the screen lock? used packages: gnome-screensaver-2.20.0-6.1 gnome-screensaver-lang-2.20.0-6.1 --8<-- geeko@g85:~> killall -9 gnome-screensaver geeko@g85:~> gnome-screensaver --no-daemon --debug > /tmp/gs.log 2>&1 -->8-- Nothing else. If you want to have the logfile then say so and I attach it. yes please Created attachment 183888 [details]
the log files from gnome-screensaver
ok, it seems to be a dbus problem: [query_session_id] gs-listener-dbus.c:2033 (13:20:05): org.freedesktop.DBus.GLib.UnmappedError.CkManagerError.Code0 raised: Unable to lookup session information for process '32759' and then the rest of the log file is about gs-listener-dbus.c waiting for something until this: gnome-screensaver: Fatal IO error 4 (Unterbrechung während des Betriebssystemaufrufs) on X server localhost:10.0. what does that German sentence mean? In any case, have you done any update recently without a reboot or something similar? Just to be sure, is any dbus process running (ps aux | grep dbus), also, does any other dbus app fail like this (like dbus-monitor, what does this show when you start the screensaver). If you see any other dbus-related problems, could you please reboot to make sure the new dbus is the one being used by all apps? No - the problem was that it does not like the command via a ssh (-X) session. When I run it directly on the laptop then it works. I only was able to capture logs when the login was to the left and not centered. Created attachment 183897 [details]
the log files from gnome-screensaver
I see nothing wrong on the log. Are you able to test these packages in a different machine? I was able to get my hands on a Acer Travelmate C300 and the effect with the login window isn't there. But that thing has another problem. The window decoration is disabled so when you login you can't move the xvkbd. But that should be handled in another bug - and I can't do that because I have to give back the Travelmate. That is probably because you don't have the GDM part applied in that machine, which should kill xvkbd when you log in. So, it seems this is something to do only with your main machine, right? And it looks to me not related at all to the gnome-screensaver change, so, JP, should we go ahead and apply the fix for 10.3? Since only part of the planned big submission was done (GDM was submitted, but not xorg-x11 and gnome-screensaver), there is a new bug in 10.3 (bug #343858), so we need to submit this ASAP. Anja, could we please get a SWAMP-ID? > Since only part of the planned big submission was done (GDM was submitted, > but not xorg-x11 and gnome-screensaver), This is not correct. I've submitted xorg-x11 for 10.3 xorg-x11.changes: ------------------------------------------------------------------- Sat Nov 10 05:20:16 CET 2007 - sndirsch@suse.de - /etc/X11/xdm/Xsetup: * /opt/gnome/sbin/gdm --> /usr/sbin/gdm (Bug #304399) * gnome-window-decorator --> gtk-window-decorator (Bug #304399) * added -always-on-top option to xvkbd call (Bug #304399) *** Bug 343906 has been marked as a duplicate of this bug. *** Stefan, your fix is still in /work/src/done/10.3 because it wasn't included in the SWAMP-ID for the other fixes (due to the gnome-screensaver problem Marco was seeing). So, yes, we need a new SWAMP-ID and I'll submit it for both your xorg-x11 fix and the gnome-screensaver one. Patchinfo submitted for 10.3 released *** Bug 345879 has been marked as a duplicate of this bug. *** |