Version: (using KDE KDE 3.5.7) Installed from: Debian testing/unstable Packages Hi, As discussed some time ago on xorg@freedesktop.org (starting from http://lists.freedesktop.org/archives/xorg/2005-December/011434.html and agreed on http://lists.freedesktop.org/archives/xorg/2005-December/011470.html), xdm & such should set the WINDOWPATH environment variable to the number of the current VT (or Xnest window ID) for braille displays to work smoothly. The idea is to run the attached code just after the X server gets started, for building the WINDOWPATH content, and to define the environment variable whenever starting X clients (_all_ of setup, login, session, etc.). See https://bugs.freedesktop.org/attachment.cgi?id=6702&action=view for the example of integration in xdm.
Created attachment 20807 [details] WINDOWPATH's content
i had some more thoughts about it and did some research. i'm no big fan of this concept, but well. but why should i hardcode this when it can be trivially scripted by using xprop at the right places?
Well, why not (that's what I've been doing in my .xsession for some time), but what are the "right places"? Remember that all X clients run by kdm potentially need this, including the X login banner.
Oh, maybe by "right place", you meant "the applications that actually use the content of WINDOWPATH"? That's what they are currently doing (because of lagging support in xdm/gdm/kdm/...), but the problem is that they can't know whether the X server was started on a console, in an Xnest window, etc. and thus for now they assume the X server was started on the console, which works 90% the time, but not when using Xnest.
the right places are obviously (for me, anyway ;) Xsetup, Xstartup, Xreset & Xsession. the Xnest/Xephyr case is way more complicated anyway, as no standardized setup procedure exists. and if XDMCP is used, everything breaks down completely. what is the "x login banner" supposed to be? the greeter?
x login banner: whatever the user sees when logging in with kdm. Indeed, the scripts could define WINDOWPATH themselves, thought it's a duplication of xprop stuff.
yes, that's the greeter. but that needs actual support anyway, so i won't bother with setting an env var for it. oh, well, the kdm patch will be about three lines, as kdm manages vts anyway (on linux, that is - porters are welcome). i will assume that the display is at the root of the path - anything else doesn't make sense.
Doesn't kdm provide a "flexy" feature like gdm? (that is: gdm is able to start a login banner in an Xnest) If not, then a trivial implementation should be fine, yes (running an X server on the console makes it at the root of the path, yes).
SVN commit 679536 by ossi: set WINDOWPATH to support some braille server. this is more a hack than anything else, but even xdm does this and our implementation is really cheap. BUG: 146537 M +9 -0 session.c --- trunk/KDE/kdebase/workspace/kdm/backend/session.c #679535:679536 @@ -763,6 +763,15 @@ memcmp( td->name, "localhost:", 10 ) ? td->name : td->name + 9 ); +#ifdef HAVE_VTS + /* Support for assistive technologies. */ + if (td->serverVT > 0) { + char vtstr[4]; + sprintf( vtstr, "%d", td->serverVT ); + env = setEnv( env, "WINDOWPATH", vtstr ); + } +#endif + if (td->ctrl.path) env = setEnv( env, "DM_CONTROL", fifoDir );