| Summary: | kdm should set the WINDOWPATH environment variable | ||
|---|---|---|---|
| Product: | [Unmaintained] kdm | Reporter: | Samuel Thibault <samuel.thibault> |
| Component: | general | Assignee: | kdm bugs tracker <kdm-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | wishlist | ||
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Debian testing | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | WINDOWPATH's content | ||
|
Description
Samuel Thibault
2007-06-08 13:39:55 UTC
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 );
|