Bug 372729

On a second computer, I do not have this issue. 

Created attachment 203305 [details]
Screenshot

it's only started on tablet pcs where you really want to have a way to type

This happen only on Tablet PCs. Please send the full output of lshal from this machine.

So "it's a feature, not a bug" (tm).

I am experiencing this on a HP Compaq tc4400 which is a Tablet PC indeed. So I understand that xvkbd is launched on this machine intentionally. Which is fine, as long as it could be closed in an obvious way. 

Since the tablet of the  HP Compaq tc4400 does not work on the Live system (at least not out-of-the-box), I see little advantage in launching a (non-functional) virtual on-screen keyboard. 

It would make sense to launch xvkbd if the tablet would work. Maybe there is a possibility to add a check and only launch xvkbd if a tablet is properly initialized by its drivers and known working.

Please let me know if I should open another bug regarding the non-working tablet and what information is needed.

No, there is no way to do such checks. It should get only launched in KDM or GDM and get killed if the user log-in to a desktop session. 

Is xvkbd launched in any other case at your machine? Which desktop do you use?

On my system (both 10.3 and 11a3 GNOME and KDE Live CDs) xvkbd stays open not only during GDM/KDM login (which is set to auto-login the default user "linux" on the live CD), but also after the user is logged in and the desktop has been launched.

Created attachment 204448 [details]
Screenshot of desktop with uncloseable xvkbd

Must be some weird race condition:

If I log out of the GNOME session that was automatically launched by the Live CD, then I get a GDM windowin which the green background of the GDM login screen is painted *over* xvkbd so that xvkbd is not usable at all.

After I have manually entered the user "linux" and a blank password, xvkbd is indeed killed as described in #6. (But only now that I have manually logged out and in again; this does *not* happen on the initial launch of GDM/GNOME on the Live CD.)

Forgot to check the "This comment provides the needed information. Remove the
status of NEEDINFO from this bug." which I am doing now ;-)

Looks as if bug #238604 is back. Reassign.

I do not understand. What is the intended behaviour? When should it be started and when killed?

It should get started in the login window of KDM/GDM/XDM and get killed if the user logs in. In this case we have autologin activated which means xvkbd should not be started (only start it if there is no autologin and the user have to login via KDM/* to the desktop)

Thanks a lot, Danny. It has been implemented that way. 

/etc/X11/xdm/Xsetup
-------------------
[...]
     xvkbd=${BINDIR}/xvkbd
[...]
#
# 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 -always-on-top
    ) & echo $! > /var/run/xvkbd.pid
  fi
fi
[...]

/etc/X11/xdm/Xstartup
---------------------
[...]
     xvkbd=${BINDIR}/xvkbd
[...]
#
# Check if the machine is a TabletPC and kill xvkbd
# to avoid multiple start on user desktop
#
$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
    /sbin/killproc -p /var/run/xvkbd.pid -TERM $xvkbd
  fi
fi

Question is, can we reproduce the issue?

Running a 10.3 or 11 Alpha 3 Live CD on the tc4400 reproduces this every time.

NEEDINFO was set to Danny.

Obviously Danny does not have any machines, on which he can reproduce this issue. Therefore I'm afraid I need to close this one as WORKSFORME. :-(

> grep -q DISPLAYMANAGER_AUTOLOGIN=""

needs to be 

  grep -q DISPLAYMANAGER_AUTOLOGIN=\"\"

Stupid me.

Fixed for Beta1.

xvkbd did not open on the Beta 1 live system by default, BUT when I left my notebook idling for some time, the screensaver-lock came up, and *after* leaving the screensaver I now permanently have xvkbd open. It has no window decorations (close button) at all, so there is no obvious way to close it. So please be so kind and re-check xvkbd interaction with the screensaver.

See comment above

This must be a different bug (not related to xdm script at all). Please open a seperate bugreport. Thanks.

*** Bug 389075 has been marked as a duplicate of this bug. ***