Re: Radeon xvideo bug
> I've experienced the following problem since I first installed my Radeon > VE card under XFree86 4.X. The bug affects the playback of any video > using the xvideo extension. > > When I play any video using any video player (e.g. xine, mplayer or vlc) > and try to minimize the application, a freeze frame of the video appears > and blocks the part of the screen where the video was running. If the > video is running full screen the entire screen is blocked by the frozen > frame. This doesn't occur if I use another video output method, as > when running "xine-V xshm movie.avi" or "mplayer -vo x11 movie.mpg". I can confirm this bug. It happened here 2 months ago when I used a radeon card (now I don't). Seems that ati driver couldn't clip xv X windows at all.
Re: Ralf's X backport compiled with the wrong g++
> Hi Ralf,
>
> the g++ libraries from your backport of the experimental packages of
> XFree86 4.3.0 you announed at [1] are compiled with g++ 2.95 although
> they must be compiled with g++ 3.2.
Nothing in woody should be compiled by 3.2.
Everything should be compiled by 2.95
> Much worse is that this will cause breakages if people use these broken
> packages together with packages from sarge/unstable or if they use other
> packages you backported together with correct future XFree86 4.3.0
> packages from sarge/unstable.
People who use mixed woody/{sarge,sid} systems without taking appropriate
care about g++ ABI WILL BREAK THEIR SYSTEMS.
Woody is g++ 2.95 based. So everything labeled "for woody" should be
compiled with 2.95 ABI. If someone wants to import something with 3.2 ABI
into his woody system, he must do that extremely careful and check all ABI
compatability issues manually.
> Package: xlibmesa4-glu
Maybe package in the backport should be renamed, to make it harder for
people to break their systems.
Bug#164379: xnest: I can confirm this bug on 4.2.1-6
Package: xnest Version: 4.2.1-6 Followup-For: Bug #164379 This bug still exists in 4.2.1-6 Xnest does not provide XKEYBOARD extension, regardleÙÙ ÝÁ +kb/-kb switches. Xnest from woody does provide XKEYBOARD. -- System Information: Debian Release: 3.0 Architecture: i386 Kernel: Linux zigzag 2.4.20 #1 þÔ× áÐÒ 10 13:44:15 MSD 2003 i686 Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R Versions of packages xnest depends on: ii libc6 2.3.1-16 GNU C Library: Shared libraries an ii xlibs 4.2.1-6X Window System client libraries ii xserver-common4.2.1-6files and utilities common to all ii zlib1g1:1.1.4-11 compression library - runtime -- no debconf information
Re: [desktop] Unix configuration nightmare
> They. Will. Not. Read. Maybe there will be somewhat less complains from those who don't read, if debconf stuff will calculate and store a checksum of autogenerated part of the file, and later don't touch it (or give extra warnings before touching) if the checksum does not match. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Running 2 X font servers
Hello. I really need to run 2 font server processes with different configuration on the same server. One should provide only small fonts for extremely slow clients that work too slow if get iso10646 fonts, and another should provide all available fonts for clients that cat handle them well. Currently I can't find any way to do that other than starting second xfs manually. I tried to start both from /etc/init.d/xfs, but this seems to lead to problems because PID file /var/run/xfs.pid seems to be hardcoded. The following code in /etc/init.d/xfs ... case "$1" in start) echo -n "Starting X font server: xfs" start-stop-daemon --start --quiet $SSD_ARGS -- -daemon || echo -n " already running" mv /var/run/xfs.pid /var/run/xfs.pid.save /usr/X11R6/bin/xfs -daemon -port 7101 -config /etc/X11/fs/config.nounicode mv /var/run/xfs.pid /var/run/xfs.nounicode.pid mv /var/run/xfs.pid.save /var/run/xfs.pid echo "." ... results into only one xfs running. Why?.. I tried make a copy of /etc/init.d/xfs to start second xfs in the way similar to first xfs, but I don't know how to call start-stop-daemon in this case. What is the correct way to solve the situation? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Running 2 X font servers
> > > What is the correct way to solve the situation? > > Use xfs-xtt or xfstt for the second server? Hmm... How stable are those font servers? Font server stop or crash is very bad because not all X servers survive after disconnect from font server - they often hang or crash. Users don't like this for some reason - it's strange but it is a fact :-). Currently I run xfs from woody package while rest X packages are from sid. Sid's xfs (from XFree 4.2.1) crashed twice for me. (But I can't reproduce the crash reliably, so bug report on this will be useless). Can those font servers provide both pcf and tt fonts? When I will have to reboot the server next time, I will try the same /etc/init.d/xfs as in my previous mail, but with "sleep 2" inserted after starting first xfs. Maybe it will work. Can't test now because can't stop running server. If this will not help, maybe I will try other font servers... But it seems that the best way is to fix xfs to accept command line argument for pid file path. I guess that is pid file conflict will be resolved, 2 xfs processes can be started just with 2 start-stop-daemon calls. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#167448: libxaw7: A bug in Xaw/StripChart.c causes incorrect scale lines in xload window
Package: libxaw7
Version: 4.2.1-3
Severity: normal
Tags: patch
Recently I tried to run xload on a high loaded server (load was more
than 10), and discovered that if window size is rather small, scale
lines are drawn incorrectly (upper than needed).
This is caused by a bug in Xaw/StripChart.c.
It draws lines with fixed integer steps. Than means that if window
height is 39 pixels, and 10 lines should be drawn to split view into 11
equal parts, lines will be drawn at 3, 6, 9, ,.., 30. So the bottom part
height will be 9 pixels while other parts height will be 2 pixels.
A patch to fix this is below. When applied, it makes part heights differ
no more than by 1 pixel.
Screenshots are at http://zigzag.lvk.cs.msu.su/~nikita/xload.png.
The top window is xload linked against patched libXaw, the bottom window
is xload linked against original libXaw.
--- StripChart.c.orig Fri Dec 14 22:54:44 2001
+++ StripChart.cSat Nov 2 17:26:15 2002
@@ -375,7 +375,7 @@
static int
repaint_window(StripChartWidget w, int left, int width)
{
-int i, j;
+int i, j, k;
int next = w->strip_chart.interval;
int scale = w->strip_chart.scale;
int scalewidth = 0;
@@ -420,8 +420,10 @@
}
/* Draw graph reference lines */
+ k = XtHeight(w) % w->strip_chart.scale;
for (i = 1; i < w->strip_chart.scale; i++) {
- j = i * ((int)XtHeight(w) / w->strip_chart.scale);
+ j = i * (XtHeight(w) / w->strip_chart.scale) +
+ ((i * k + w->strip_chart.scale/2) /
w->strip_chart.scale);
XDrawLine(dpy, win, w->strip_chart.hiGC, left, j,
scalewidth, j);
}
}
@@ -443,7 +445,7 @@
MoveChart(StripChartWidget w, Bool blit)
{
double old_max;
-int left, i, j;
+int left, i, j, k;
int next = w->strip_chart.interval;
if (!XtIsRealized((Widget)w))
@@ -492,8 +494,10 @@
/* Draw graph reference lines */
left = j;
+k = XtHeight(w) % w->strip_chart.scale;
for (i = 1; i < w->strip_chart.scale; i++) {
- j = i * (XtHeight(w) / w->strip_chart.scale);
+ j = i * (XtHeight(w) / w->strip_chart.scale) +
+ ((i * k + w->strip_chart.scale/2) / w->strip_chart.scale);
XDrawLine(XtDisplay((Widget)w), XtWindow((Widget)w),
w->strip_chart.hiGC, left, j, XtWidth(w), j);
}
@@ -554,7 +558,7 @@
StripChartWidget w = (StripChartWidget)widget;
XPoint *points;
Cardinal size;
-int i;
+int i, k;
if (w->strip_chart.scale <= 1) {
XtFree((char *)w->strip_chart.points);
@@ -569,8 +573,12 @@
/* Draw graph reference lines into clip mask */
+k = XtHeight(w) % w->strip_chart.scale;
for (i = 1; i < w->strip_chart.scale; i++) {
points[i - 1].x = 0;
- points[i - 1].y = XtHeight(w) / w->strip_chart.scale;
+ points[i - 1].y = i * (XtHeight(w) / w->strip_chart.scale) +
+ ((i * k + w->strip_chart.scale/2) / w->strip_chart.scale);
}
+for (i = w->strip_chart.scale - 1; i > 1; i--)
+ points[i - 1].y -= points[i - 2].y;
}
-- System Information:
Debian Release: 3.0
Architecture: i386
Kernel: Linux sercond 2.4.19 #1 óÂÔ óÅÎ 28 15:05:51 MSD 2002 i686
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R
Versions of packages libxaw7 depends on:
ii libc6 2.3.1-3GNU C Library: Shared libraries an
ii xlibs 4.2.1-3X Window System client libraries
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#167605: xfs should have configurable pid file
Package: xfs
Version: 4.2.1-3
Severity: normal
Tags: patch
In current xfs package, pid file is hardcoded to /var/run/xfs.pid.
Hardcoded pid file leads to problems if more than one font server should
run (e.g. one providing unicode fonts for fast clients, and another one
not providing unicode fonts for slow clients).
The following patch adds -pid option for xfs that may be used to change
pid file.
diff -ur xfs.orig/os/utils.c xfs/os/utils.c
--- xfs.orig/os/utils.c Mon Nov 4 00:18:04 2002
+++ xfs/os/utils.c Sun Nov 3 23:56:29 2002
@@ -219,7 +219,7 @@
static void
usage(void)
{
-fprintf(stderr, "usage: %s [-config config_file] [-port tcp_port] [-droppriv]
[-daemon] [-nodaemon] [-user user_name]\n",
+fprintf(stderr, "usage: %s [-config config_file] [-port tcp_port] [-droppriv]
+[-daemon] [-nodaemon] [-user user_name] [-pid pid_file]\n",
progname);
exit(1);
}
@@ -338,6 +338,11 @@
} else if (!strcmp(argv[i], "-cf") || !strcmp(argv[i], "-config")) {
if (argv[i + 1])
configfilename = argv[++i];
+ else
+ usage();
+ } else if (!strcmp(argv[i], "-pid")) {
+ if (argv[i + 1])
+ pidFile = argv[++i];
else
usage();
}
diff -ur xfs.orig/xfs.man xfs/xfs.man
--- xfs.orig/xfs.manFri Dec 14 23:01:32 2001
+++ xfs/xfs.man Mon Nov 4 00:10:33 2002
@@ -49,6 +49,7 @@
[\-nodaemon]
[\-port \fItcp_port\fP]
[\-user \fIusername\fP]
+[\-pid \fIpid_file\fP]
.SH DESCRIPTION
.PP
.I Xfs
@@ -99,6 +100,10 @@
This is equivalent to
.B \-droppriv
except that xfs will run as user \fIusername\fR.
+.TP 8
+.B \-pid pid_file
+Save daemon process id into \fIpid_file\fR, instead of default
+\fI/var/run/xfs.pid\fR.
.SH "SIGNALS"
.TP 8
.I SIGTERM
-- System Information:
Debian Release: 3.0
Architecture: i386
Kernel: Linux sercond 2.4.19 #1 óÂÔ óÅÎ 28 15:05:51 MSD 2002 i686
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R
Versions of packages xfs depends on:
ii debconf 1.2.14 Debian configuration management sy
ii libc6 2.3.1-3GNU C Library: Shared libraries an
ii zlib1g1:1.1.4-6 compression library - runtime
-- debconf information:
* xfs/default_100dpi:
* xfs/default_nolisten_tcp:
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#168791: xfs: A fix for xfs segfault
Package: xfs
Version: 4.2.1-3
Severity: important
Tags: patch
After upgrade to Xfree 4.2.1, several times we experienced xfs crashes.
(quite bad, because it causes several user sessions on terminals to crash)
At last one of our users found an reprodusable sequence of actions to
crash xfs. So I've tracked the bug.
It dereferences a NULL pointer in xc/lib/font/fontfile/fontenc.c
The following patch fixes the problem:
--- fontenc.c.orig Tue Nov 12 17:11:37 2002
+++ fontenc.c Tue Nov 12 17:25:29 2002
@@ -744,7 +744,7 @@
/* Check whether the name is already known for this encoding */
if(strcasecmp(encoding->name, encoding_name) == 0) {
found = 1;
-} else {
+} else if (encoding->aliases) {
for(alias=encoding->aliases; *alias; alias++)
if(!strcasecmp(*alias, encoding_name)) {
found = 1;
@@ -763,17 +763,21 @@
if(new_name == NULL)
return NULL;
strcpy(new_name, encoding_name);
-for(alias = encoding->aliases; *alias; alias++)
-numaliases++;
+ if (encoding->aliases) {
+for(alias = encoding->aliases; *alias; alias++)
+numaliases++;
+ }
new_aliases = (char**)xalloc((numaliases+2)*sizeof(char*));
if(new_aliases == NULL) {
xfree(new_name);
return NULL;
}
-memcpy(new_aliases, encoding->aliases, numaliases*sizeof(char*));
+if (encoding->aliases) {
+ memcpy(new_aliases, encoding->aliases, numaliases*sizeof(char*));
+ xfree(encoding->aliases);
+ }
new_aliases[numaliases] = new_name;
new_aliases[numaliases+1] = NULL;
-xfree(encoding->aliases);
encoding->aliases = new_aliases;
}
-- System Information:
Debian Release: 3.0
Architecture: i386
Kernel: Linux zigzag 2.4.19 #1 óÒÄ îÏÑ 6 17:54:30 MSK 2002 i686
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R
Versions of packages xfs depends on:
ii debconf 1.2.14 Debian configuration management sy
ii libc6 2.3.1-3GNU C Library: Shared libraries an
ii zlib1g1:1.1.4-1 compression library - runtime
-- debconf information:
* xfs/default_100dpi:
* xfs/default_nolisten_tcp:
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Radeon xvideo bug
> I've experienced the following problem since I first installed my Radeon > VE card under XFree86 4.X. The bug affects the playback of any video > using the xvideo extension. > > When I play any video using any video player (e.g. xine, mplayer or vlc) > and try to minimize the application, a freeze frame of the video appears > and blocks the part of the screen where the video was running. If the > video is running full screen the entire screen is blocked by the frozen > frame. This doesn't occur if I use another video output method, as > when running "xine-V xshm movie.avi" or "mplayer -vo x11 movie.mpg". I can confirm this bug. It happened here 2 months ago when I used a radeon card (now I don't). Seems that ati driver couldn't clip xv X windows at all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ralf's X backport compiled with the wrong g++
> Hi Ralf,
>
> the g++ libraries from your backport of the experimental packages of
> XFree86 4.3.0 you announed at [1] are compiled with g++ 2.95 although
> they must be compiled with g++ 3.2.
Nothing in woody should be compiled by 3.2.
Everything should be compiled by 2.95
> Much worse is that this will cause breakages if people use these broken
> packages together with packages from sarge/unstable or if they use other
> packages you backported together with correct future XFree86 4.3.0
> packages from sarge/unstable.
People who use mixed woody/{sarge,sid} systems without taking appropriate
care about g++ ABI WILL BREAK THEIR SYSTEMS.
Woody is g++ 2.95 based. So everything labeled "for woody" should be
compiled with 2.95 ABI. If someone wants to import something with 3.2 ABI
into his woody system, he must do that extremely careful and check all ABI
compatability issues manually.
> Package: xlibmesa4-glu
Maybe package in the backport should be renamed, to make it harder for
people to break their systems.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xprt-xprintorg taking over xprt: now or later?
> On Tue, Dec 07, 2004 at 11:09:31AM +1100, Drew Parsons wrote: >> I guess we can do it now. xprt (xfree86) does not work and Fabio was >> already prepared to remove it now before sarge. > > Of course, neither does xprt-xprintorg, but that's a minor quibble. :) > Does *anything* besides Mozilla care about whether or not it exists? From > a user's perspective, I can't imagine that it's at all important to > replace the one with the other for Sarge. > > Checking reverse depends... no, nothing other than Mozilla and friends > deps > on it, and they don't even dep on it, they only recommend it. So who > cares, really? Tried ever to print non iso8859-1 characters from mozilla? It isn't impossible without xprt, but it is really hacky ...
Re: X Strike Force X.Org X11 SVN commit: r338 - tags
> Author: dnusinow > Date: 2005-07-12 12:14:46 -0500 (Tue, 12 Jul 2005) > New Revision: 338 > > Added: >tags/6.8.2.dfsg.1-1/ > Log: > Tagging 6.8.2.dfsg.1-1 release. Note that due to issues with svn access, > there is a dependency change of xprt-xprintorg -> xprint that was made for > this tagged version but was not incorporated in to the actual package > uploaded. Svn allows to fix this easily - tags are just copies, so it is possible to revert corresponding patch inside tags/6.8.2.dfsg.1-1/ tree. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Keyboard lockup after X startup; possible cause
Hello. Several people probably faced the problem that after initial system bootup, and startup of *dm, keyboard does not work. Suggested workaround was to add implicit 'vtX' parameter to X server command line in Xservers file. I've never seen an explanation of what is actually hapenning, and why that workaround helps. Recently I've installed kde 3.4 packages from experimental on one of my systems, and faced that keyboard problem again. And the suggested workaround was not possible, because it seems that newer kdm does not use Xservers file. After logging into system remotely, I found that X was started with 'vt2' parameter. While trying to fix the situation, I probably guessed what is causing lockups. Unlike some other distributions, Debian treats *dm similar to other services, and starts it from /etc/init.d script while syste, startup. So *dm is started *before* getty's start for consoles. Then *dm starts X server which may scan for a free vt (or, in case of recent kdm, it scans for a free vt itself). At this point, there is a race. Either getty's fo vt2-vt6 are already started, and search result into "really free" vt, and everything goes ok. Or getty is not yet started, and X is started on vt on which later getty is started. In this case, getty "initializes" vt *after* X, and into some state incompatable with X, and keyboard no longer works. I don't know which is the correct way to fix it. Possible ways: *) ensure that X is never started on vt on which getty is going to be started - in this case, having default Xservers files to set explicit vtN is enough, and kdm 3.4 should provide some way to ensure that it will not choose vt on which getty will be started later, *) debian should not treat *dm like other services, and start it after getty's, not before them *) some other way? Nikita pgpuuKige4TW4.pgp Description: PGP signature
Re: Xsession and login shells
> Marc Wilson wrote: >> Bob Proulx wrote: >> > Xsession does not spawn a login shell. >> >> Why should it? > > * Because it provides the most user convenient way for the user to log > in and have their login environment. > > * Because not doing so has been a long term problem for users. > > * Because not doing so causes there to be a difference between logging > in with xdm versus logging in with ssh. Note that *dm have their own Xsession files (e.g. /etc/kde3/kdm/Xsession fro kdm), that just source /etc/X11/Xsession. I believe that dm-specific Xsessions should launch login shell.
Re: Bug#233818: Bug#233867: "Provides: xlib6g" needed in 4.3.0
> On Fri, 20 Feb 2004, Branden Robinson wrote: > > [...] >> > The question is: Since the last xlib6g packages are empty packages >> > anyways... do you really need to Conflict: it? >> >> I'd really like to force them off the system. > > Could conflicting with xlib6g less-than say 4.3.0 help in getting us to a > workable compromise? Why not just re-create a binary package of old software, avoiding unwanted dep? dpkg-deb -x old-package.deb tmp/ dpkg-deb --control old-package.deb tmp/DEBIAN dpkg-deb -b tmp .
Strange point in xserver-xfree86.config
Hello. I'm experimenting with preloading default values to debconf database. Among others, I was playing with the question about method of display configuration (simple/medium/advanced). I wanted to preload answer "Simple", but still let user to change it. So I preload the following: Name: xserver-xfree86/config/monitor/selection-method Template: xserver-xfree86/config/monitor/selection-method Value: Simple Owners: xserver-xfree86 Since I want the question to be asked, I don't set "seen" flag. However, when I try to install xserver-xfree86 package, I see the question with "Advanced" selected by default. I looked at the config script, and found the flooing code (near line 1569): if [ "$RET" = "true" ]; then db_subst xserver-xfree86/config/monitor/selection-method choices "Medium, Advanced" db_subst xserver-xfree86/config/monitor/selection-method default "Medium" else # not an LCD db_subst xserver-xfree86/config/monitor/selection-method choices "Simple, Medium, Advanced" db_subst xserver-xfree86/config/monitor/selection-method default "Simple" fi auto_answer db_input "$(priority_ceil $PRIORITY)" xserver-xfree86/config/monitor/selection-method "Advanced" That is, showing "Advanced" by default is hardcoded. Isn't this a bug? Perhaps default selection should be one set by the above lines, not "Advanced"? Also, maybe auto_answer routine should be fixed to better support preloading debconf values? In particular, if something is preloaded, use that instead of provided in parameter 4? Patch for this (not tested) is something like @@ -846,8 +846,8 @@ debug_echo "auto_answer: (reconfiguring) preserving existing answer \"$RET\"" else # not reconfiguring; has the question been seen before? -db_fget "$TEMPLATE" seen -if [ "$RET" = "true" ]; then +db_get "$TEMPLATE" +if [ -n "$RET" ]; then db_get "$TEMPLATE" debug_echo "auto_answer: (not reconfiguring) preserving existing answer \"$RET\"" else
Re: Bug#241062: base-config should start xfs before *dm
> On Wed, Mar 31, 2004 at 05:57:55PM -0500, Joey Hess wrote: > > I don't think it's base-config's job to work around what looks like a > > bug in xdm for not starting the daemon on initial install. Forwarding > > to the XSF. > > This done for two reasons: > > 1) historical > 2) display managers are not like other daemons; they start an X server > on a local VT by default which yanks the console away > > I'm willing to listen to a case against both of these. There was a typo. It's actually not about xdm, it's about xfs.
Bug#242216: xserver-xfree86.config hardcodes different defaults for display selection method on different priorities
Package: xserver-xfree86 Version: 4.3.0-7 Severity: normal Tags: patch xserver-xfree86.config contains the following code: ... if [ "$RET" = "true" ]; then db_subst xserver-xfree86/config/monitor/selection-method choices "Medium, Advanced" db_subst xserver-xfree86/config/monitor/selection-method default "Medium" else # not an LCD db_subst xserver-xfree86/config/monitor/selection-method choices "Simple, Medium, Advanced" db_subst xserver-xfree86/config/monitor/selection-method default "Simple" fi auto_answer db_input "$(priority_ceil $PRIORITY)" xserver-xfree86/config/monitor/selection-method "Advanced" ... Thus default answer for xserver-xfree86/config/monitor/selection-method is "Simple" or "Medium" (which is good for non-technical users), but if debconf actually asks the question, the default shown answer is hardcoded to "Advanced". Since users tend to accept all defaults they see (even after a help screen was shown describing what the selections mean), too often they select this default and are faced with questions about frequences they can't understand. And even can't go back at that point. So it seems better to show a "silly-safe" choise by default. I.e. the same as is set in the case when question is not asked. --- xserver-xfree86.config.orig 2004-04-05 16:02:07.0 +0400 +++ xserver-xfree86.config 2004-04-05 16:06:21.0 +0400 @@ -1568,13 +1568,14 @@ MONITOR_IS_LCD="$RET" if [ "$RET" = "true" ]; then db_subst xserver-xfree86/config/monitor/selection-method choices "Medium, Advanced" - db_subst xserver-xfree86/config/monitor/selection-method default "Medium" + DEFAULT="Medium" else # not an LCD db_subst xserver-xfree86/config/monitor/selection-method choices "Simple, Medium, Advanced" - db_subst xserver-xfree86/config/monitor/selection-method default "Simple" + DEFAULT="Simple" fi -auto_answer db_input "$(priority_ceil $PRIORITY)" xserver-xfree86/config/monitor/selection-method "Advanced" +db_subst xserver-xfree86/config/monitor/selection-method default $DEFAULT +auto_answer db_input "$(priority_ceil $PRIORITY)" xserver-xfree86/config/monitor/selection-method $DEFAULT db_get xserver-xfree86/config/monitor/selection-method case "$RET" in
Bug#242216: xserver-xfree86.config hardcodes different defaults for display selection method on different priorities
> Your patch is incomplete; there is no auto_answer counterpart for the > "Simple" and "Medium" monitor selection methods. Could you please explain what you mean? I've looked at the code of auto_answer, and I fail to find what else is needed to change default displayed answer. auto_answer routine seems do put it's fourth argiment to debconf database using db_set. So in current code it puts "Advanced" there, in my patch it will put $DEFAULT there instead. I fail to understand why this is not enough.
Bug#242216: xserver-xfree86.config hardcodes different defaults for display selection method on different priorities
tag 242216 + patch thanks > > Could you please explain what you mean? > > Sure. > ... > I am referring to the large case statement at line 990 of > xserver-xfree86.config.in[1]. > > The Simple) and Medium) cases have no auto-answer logic. Your patch > should not be applied until they do. I'm not sure I understand why auto_answer logic is needed there, but anyway the attached patch is probably what you wish. Index: xserver-xfree86.config.in === --- xserver-xfree86.config.in (revision 1225) +++ xserver-xfree86.config.in (working copy) @@ -978,19 +978,19 @@ MONITOR_IS_LCD="$RET" if [ "$RET" = "true" ]; then db_subst xserver-xfree86/config/monitor/selection-method choices "Medium, Advanced" - db_subst xserver-xfree86/config/monitor/selection-method default "Medium" + DEFAULT="Medium" else # not an LCD db_subst xserver-xfree86/config/monitor/selection-method choices "Simple, Medium, Advanced" - db_subst xserver-xfree86/config/monitor/selection-method default "Simple" + DEFAULT="Simple" fi -auto_answer db_input "$(priority_ceil $PRIORITY)" xserver-xfree86/config/monitor/selection-method "Advanced" +db_subst xserver-xfree86/config/monitor/selection-method default $DEFAULT +auto_answer db_input "$(priority_ceil $PRIORITY)" xserver-xfree86/config/monitor/selection-method $DEFAULT db_get xserver-xfree86/config/monitor/selection-method case "$RET" in Simple) -db_input "$(priority_ceil $PRIORITY)" xserver-xfree86/config/monitor/screen-size || debug_report_status "db_input $(priority_ceil $PRIORITY) xserver-xfree86/config/monitor/screen-size" "$?" -db_go +auto_answer db_input "$(priority_ceil $PRIORITY)" xserver-xfree86/config/monitor/screen-size "15 inches (380 mm)" db_get xserver-xfree86/config/monitor/screen-size case "$RET" in 'Up to 14 inches (355 mm)') @@ -1016,8 +1016,7 @@ esac ;; Medium) -db_input "$(priority_ceil $PRIORITY)" xserver-xfree86/config/monitor/mode-list || debug_report_status "db_input $(priority_ceil $PRIORITY) xserver-xfree86/config/monitor/mode-list" "$?" -db_go +auto_answer db_input "$(priority_ceil $PRIORITY)" xserver-xfree86/config/monitor/mode-list "1024x768 @ 75Hz" db_get xserver-xfree86/config/monitor/mode-list case "$RET" in "640x480 @ 60Hz")
Re: autologin with xdm?
> How can I autologin after boot with xdm? > I'm tired of typing name and password each day at power up. > The maintainer suggested I try another display manager, but all I use > is icewm and don't need or understand the glitz. I think xdm does not support this. If you really don't want to install dm that supports this, you may not use xdm at all, instead make your system to run something like su username /usr/X11R6/bin/startx on the end of boot sequence. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#195418: a patch to fix this
tag 195418 +patch
thanks
Oh, seems that I forgot to attach my patch when I reported this bug :(
Well, the patch is attached to this mail.
--- config.old 2003-07-31 18:42:00.0 +0400
+++ config 2003-07-31 18:41:55.0 +0400
@@ -508,11 +508,25 @@
# collect information about installed video card(s), if possible
if which discover > /dev/null 2>&1; then
DISCOVERED_VIDEO=$(discover_video)
- NCARDS=$(echo "$DISCOVERED_VIDEO" | wc -l)
- SERVERS=$(echo "$DISCOVERED_VIDEO" | awk 'BEGIN { FS="\t" } {print $2}' | grep -v unknown | sort | uniq)
- NSERVERS=$(echo "$SERVERS" | wc -l)
- DRIVERS=$(echo "$DISCOVERED_VIDEO" | awk 'BEGIN { FS="\t" } {print $NF}' | grep -v unknown | sort | uniq)
- NDRIVERS=$(echo "$DRIVERS" | wc -l)
+ if test -n "$DISCOVERED_VIDEO"; then
+NCARDS=$(echo "$DISCOVERED_VIDEO" | wc -l)
+SERVERS=$(echo "$DISCOVERED_VIDEO" | awk 'BEGIN { FS="\t" } {print $2}' | grep -v unknown | sort | uniq)
+if test -n "$SERVERS"; then
+ NSERVERS=$(echo "$SERVERS" | wc -l)
+else
+ NSERVERS=0
+fi
+DRIVERS=$(echo "$DISCOVERED_VIDEO" | awk 'BEGIN { FS="\t" } {print $NF}' | grep -v unknown | sort | uniq)
+if test -n "$DRIVERS"; then
+ NDRIVERS=$(echo "$DRIVERS" | wc -l)
+else
+ NDRIVERS=0
+fi
+ else
+NCARDS=0
+NSERVERS=0
+NDRIVERS=0
+ fi
if [ $NCARDS -gt 1 ]; then
MULTIHEAD=yes
fi
Re: autologin with xdm?
> How can I autologin after boot with xdm? > I'm tired of typing name and password each day at power up. > The maintainer suggested I try another display manager, but all I use > is icewm and don't need or understand the glitz. I think xdm does not support this. If you really don't want to install dm that supports this, you may not use xdm at all, instead make your system to run something like su username /usr/X11R6/bin/startx on the end of boot sequence.
Bug#195418: a patch to fix this
tag 195418 +patch
thanks
Oh, seems that I forgot to attach my patch when I reported this bug :(
Well, the patch is attached to this mail.
--- config.old 2003-07-31 18:42:00.0 +0400
+++ config 2003-07-31 18:41:55.0 +0400
@@ -508,11 +508,25 @@
# collect information about installed video card(s), if possible
if which discover > /dev/null 2>&1; then
DISCOVERED_VIDEO=$(discover_video)
- NCARDS=$(echo "$DISCOVERED_VIDEO" | wc -l)
- SERVERS=$(echo "$DISCOVERED_VIDEO" | awk 'BEGIN { FS="\t" } {print $2}' | grep -v unknown | sort | uniq)
- NSERVERS=$(echo "$SERVERS" | wc -l)
- DRIVERS=$(echo "$DISCOVERED_VIDEO" | awk 'BEGIN { FS="\t" } {print $NF}' | grep -v unknown | sort | uniq)
- NDRIVERS=$(echo "$DRIVERS" | wc -l)
+ if test -n "$DISCOVERED_VIDEO"; then
+NCARDS=$(echo "$DISCOVERED_VIDEO" | wc -l)
+SERVERS=$(echo "$DISCOVERED_VIDEO" | awk 'BEGIN { FS="\t" } {print $2}' | grep -v unknown | sort | uniq)
+if test -n "$SERVERS"; then
+ NSERVERS=$(echo "$SERVERS" | wc -l)
+else
+ NSERVERS=0
+fi
+DRIVERS=$(echo "$DISCOVERED_VIDEO" | awk 'BEGIN { FS="\t" } {print $NF}' | grep -v unknown | sort | uniq)
+if test -n "$DRIVERS"; then
+ NDRIVERS=$(echo "$DRIVERS" | wc -l)
+else
+ NDRIVERS=0
+fi
+ else
+NCARDS=0
+NSERVERS=0
+NDRIVERS=0
+ fi
if [ $NCARDS -gt 1 ]; then
MULTIHEAD=yes
fi
Getting X server crash backtrace
Hello. On one of Debian systems I administer, user does experience random X server crashes. The crashes seem not to be reproducable by exact action sequence, but they do happen every 2-3 hours. This happens both with 4.2 from testing and 4.3 from experimental. I don't think it is bad memory or similar. I guess it is a bug in X server itself, and I want to catch it. I've done some work inside X server in past, and used to run X server from gdb, using another computer as debugging console. The problem is that in this case, computer in question is standalone (no network at all). Is there any recommended way to get the crash backtrace from crashed X server? What I want is to do some setup on the user's computer, and let user do his work, but on server crash I want a core file to be generated, that can be analyzed by gdb later. I guess -dbg X server package is needed... If debugging such issues is documented anywhere, please point me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting X server crash backtrace
> On Thu, Oct 16, 2003 at 12:26:17PM +0400, Nikita V. Youshchenko wrote: > > I guess -dbg X server package is needed... > > I am disappointed that you reached this conclusion, completle with > speculation as to how such a package would be named, and then didn't > even bother to look for one. > > % apt-cache search xserver | grep -i debug > xserver-xfree86-dbg - the XFree86 X server (static version with > debugging symbols) You misunderstood me. I know about this package. But I would like to know what will be next after 45 megabyte download (a large one for me). I can't just run it under gdb on non-networked workstation - I will get a system hang on the crash event. The question was - how to get a crashed server's core? Perefably without human interaction - the machine in question is located at user's home, I can't sit for hours there waiting for a crash ... If there is documentation in xserver-xfree86-dbg, just tell me about it, and I will proceed and download it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#218169: "CGA snow" effect on Radeon 7500 at 24bpp
Package: xserver-xfree86 Version: 4.3.0-0pre1v4 Tags: experimental Architecture: i386 After upgrading X from 4.2 to current 4.3 packages from XSF, I've got the following problem on several of workstations here. If X is started on 1280x1024 24bpp, there is well-visible and really annoying "CGA snow" effect when some object moves over the screen. (That means, to the right of the moving object there are lots of flickering white dots and short horizontal lines). Option "XaaNoScreenToScreenCopy" takes the effect away, but desktop becomes unacceptably slow. Other options (both Xaa-related and DRI-related) seem not to change the effect. This effect disappears if X is started an lower bpp (16bpp). This happens with video card that lspci detects as "ATI Technologies Inc Radeon RV200 QW [Radeon 7500]". XF86Config and XFree86 log files are attached. In the past, I've noticed the same effect of a computer with S3 card, but I thought that it could be hardware problem. In this case, it is definitly driver problem, because earlier versions of X (e.g. 4.2) worked correctly. XF86Config-4.bz2 Description: BZip2 compressed data XFree86.1.log.bz2 Description: BZip2 compressed data
Bug#218169: "CGA snow" effect on Radeon 7500 at 24bpp
> See http://bugs.xfree86.org/show_bug.cgi?id=175 . [From that bug discussion] > The radeon driver in current CVS contains bandwidth management code > by Hui Yu which might help this. Would be great if someone seeing this > problem could verify that. If there is pre-build driver binary available that may be loaded into X server from Debain experimental, I will test it and report the result. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Please assist debugging X server crash
Hello
(the above happens with package from debian/experimental, with ATI
Technologies Inc Rage 128 RF video card)
One of users here experienced a nearly-reproducable X server crash
("nearly-reproducable" means that he does a compex sequence of actions,
and at some moment it leads to the crash, he could reproduce that for me
with XFree86-debug started from gdb, but the exact user action that causes
the crash is unclear).
So I see that X server receives SIGSEGV.
I have a core file.
(gdb) where
#0 0x08498622 in CopyGC (pgcSrc=0x94ec930, pgcDst=0x90ba598, mask=8387584)
at gc.c:771
#1 0x0848611f in ProcCopyGC (client=0x8f0e9c0) at dispatch.c:1607
#2 0x084837c4 in Dispatch () at dispatch.c:450
#3 0x0849acc4 in main (argc=5, argv=0xbd64, envp=0xbd7c) at
main.c:469
gc.c:771 line is completely safe (it only reads a local variable).
But: 'print $eip' shows that $eip is not at instruction boundary!
And instruction decode started from $eip gives an instruction with invalid
memory access, causing SIGSEGV.
I've analysed the assembly code for CopyGC(). It looks ok, at least there
are no invalid control-pass instructions.
I've analysed the stack - it also looks ok, nothing seems broken.
The only idea I have is that in some function called from CopyGC (there are
several, including indirect drivers calls) some sort of out-of-bounds
memory write happens that breaks the return address in the stack, so when
function returns back to CopyGC(), the control arises at invalid point,
causing SIGSEGV.
So I'm interested what to do next to locate the bug. I can provide any
technical information, including the core file (45 megabytes), or do some
analysis myself if someone will assist me on that.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please assist debugging X server crash
Never mind. It was a bug (process esp breakage in interrupt handler) in a kernel module I was playing with and forgot to unload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#218919: Call for OOo user interface font size testers
After I've configured dpi correctly on all servers, I do get correct font
sizes everywhere in OpenOffice - both with 1.1.0-2 and 1.1.0-2.3pre1
What have I done:
- physically measured the visible picture dimensions for monitors, and
added correct "DisplaySize" parameter to XF86Config-4 (Section "Monitor").
For 17'' monitor, it is 320x240 mm.
- removed any "-dpi XXX" parameters from command-line of X (in my case, X
command line is in /etc/kde3/kdm/Xservers)
- added the following script as /etc/X11/Xsession.d/95dpi:
dpi=`xdpyinfo |
awk '/resolution/ {split($2, x, "x"); print(int((x[1]+x[2])/2))}'`
echo "Xft.dpi: $dpi" | xrdb -merge
So both X protocol-level dpi and Xft.dpi are calculated to correct value
automatically depending on selected display resolution and physical
monitor size.
After that, I do get correct font sizes.
Even more, the displayed size of paper sheet displayed by OpenOffice.org at
scale=100% is the same as the size of physical paper sheet!
Also I get the same physical font size on different display resolutions. I
verified it, it works.
Perhaps such auto-calculation of dpi should become Debian default.
> [Sorry, I pressed send to early and a draft went to debian-openoffice]
>
> Hi,
>
> I've uploaded 1.1.0-2.3pre1 packages of openoffice.org and
> openoffice.org-bin to the unstable section of our mirrors [1], and I'd
> be grateful if people who have had problems with the user interface font
> size in 1.1.0-1 and 1.1.0-2 could try them out before they go to
> unstable, and let us know the results.
>
> Here is a summary of the font changes that have been made that I am
> aware of since we started incorporating Xmian's patches, to help you
> understand OOo's behaviour between the versions:
>
> 1.1.0-1
>
> * Added Ximian fontconfig patches. With these, OOo queries
> fontconfig for a list of available fonts, but all other font
> displaying/sizing/formatting etc is still done in the usual
> way. That's why OOo did not start supporting any other
> fontconfig features such as ttc support, artifical italics,
> antialising etc.
>
> * Added Ximian patch to remove workarounds for displays < 96 DPI,
> so that UI fonts and documents zoomed at 100% show at true size
> on displays with a lower DPI.
>
> 1.1.0-2
>
> * KDE integration: Previously, OOo only used the name of the
> default KDE font. Patched to also retrieve the font size,
> italic/bold setting for both the general font and the menu font.
>
> * Increased default font size for non-KDE/Gnome users from '8' to
> '12' (not sure if this really is a point size). That was a
> mistake; backed out for -3.
>
> 1.1.0-2.3pre1
>
> * Backed out patch to increase default font size; it now only
> slightly enlarges it (maybe this needs removing completely?)
>
> * Added patch to make it possible to select which desktop
> integration OOo chooses. Set OOO_FORCE_DESKTOP to 'gnome',
> 'kde' or 'none' to force which desktop integration OOo uses.
> * OOO_FORCE_DESKTOP=kde
> * OOO_FORCE_DESKTOP=gnome
> * OOO_FORCE_DESKTOP=kde
>
> * KDE integration: Fixed the 'use system UI fonts' setting - this
> never worked in KDE integration mode. Added Nikita's patch to
> check KDEDIR and KDEHOME for a user-supplied KDE directory.
>
> * Gnome and KDE integration: Added gui-scale-ruler, which reduces
> the toolbar font slightly to improve the ruler appearance.
>
> * Gnome integration: merged openoffice.org-gnome back into the
> main package, since most users did not seem to find it. The
> group of users who had installed openoffice.org but not -gnome
> will now find their desktop integration works again and the
> icons are back.
>
> So, let the testing begin :) I've purposely not uploaded to unstable
> yet because I'm not sure if there's still something I've overlooked. If
> you do still feel something is wrong, I'd appreciate the following
> information:
>
> - Which desktop integration mode you use (and double check that OOo
> really did detect your desktop correctly by using OOO_FORCE_DESKTOP to
> confirm)?
>
> - Which DPI setting is your X server set to? Is it the correct setting
> for your display size and resolution? Is the Xft.dpi property set?
>
> - Can you provide a screenshot, if OOo is wildly different from other
> programs on your desktop?
>
> Thanks for your feedback,
> Chris
>
> [1] http://openoffice.debian.net/mirrors.html - I pushed the packages to
> ftp.freenet.de; other mirrors may not have synced yet.
Setting DisplaySize in dexconf-generated XF86Config ?
Some experiments show that to get best results with OpenOffice.org (and
probably other packages), X server's DPI value should be set to real
monitor DPI.
XFree86 seems to have an excellent way to do that.
In XF86Config-4, in section "Monitor", one can write
DisplaySize 320 240
and specify physical monitor dimensions that way.
Using that information, X server will calculate correct DPI value.
Some modern software (xft/fontconfig-based) uses Xft.dpi resource; this
may be set by adding something like
dpi=`xdpyinfo |
awk '/resolution/ {split($2, x, "x"); print(int((x[1]+x[2])/2))}'`
echo "Xft.dpi: $dpi" | xrdb -merge
to /etc/X11/Xsession.d/95dpi
Perhaps a question about physical monitor dimensions should be added to
xserver-xfree86 debconf templates. It should have pre-defined values for
common situations (such as 320x240 mm for 17'' monitors), and allow user
to enter explicit values if he wishes (or not to set DisplaySize at all).
I believe it's much better than just assume 100dpi by default (as it is
now).
Idea for smoother upgrade from pre-4.3 XFree to 4.3
Hello. To get correctly configured russian keyboard In pre-4.3 xkb configuration, we had to write Option "XkbLayout" "ru" In 4.3, we have to write Option "XkbLayout" "us,ru" because setting it to just "ru" now gives only russian letters input, instead of both english and russian (which is basically required). I guess the same situation may be with other languages also. The upgrade from pre-4.3 versions of xserver-xfree86 package will be smoother, if the upgrade scripts will change the xkb settings to new style automatically. Or at least warn the user that he needs the change.
Bug#415292: libgl1-mesa-glx: assertion failure in libGL.so.1
> Hi Nikita, > > It might be good to test Mesa 6.5.3-1 which has been uploaded to > experimental today. The upstream bug that you reported has not been > touched, but there are so many changes since 6.5.2 that it's probably > worth a try. Hello, and sorry for long delay. I've tried it, and the issue is not fixed. Wine started on Xvnc4 16bpp session still gets same assertion failure. However, I found that wine works OK (at least without assertion failure being discussed) on Xvnc built from fedora sources (which is based on Xorg 7.x, while debian's Xvnc4 is based on Xfree 4.x). pgpkfMi3mrbdd.pgp Description: PGP signature
Bug#242216: xserver-xfree86.config hardcodes different defaults for display selection method on different priorities
> tags 242216 - patch > reassign 242216 xserver-xorg > kthxbye > > On Thu, Apr 8, 2004 at 11:29:46 +0400, Nikita V. Youshchenko wrote: > > > > Could you please explain what you mean? > > > > > > Sure. > > > ... > > > I am referring to the large case statement at line 990 of > > > xserver-xfree86.config.in[1]. > > > > > > The Simple) and Medium) cases have no auto-answer logic. Your patch > > > should not be applied until they do. > > > > I'm not sure I understand why auto_answer logic is needed there, but > > anyway the attached patch is probably what you wish. > > Hi, > > is this bug still a problem for you with the current xserver-xorg > package configuration? Hi. Unfortunately, too many time has passed since I reported that bug. I'm currently completely out of context. I've tried to check the current situation - but I even can't find what is modern equivalent of old xserver-xfree86.config file. Probably this bug should be just closed. Nikita pgpiRfhZSh5mt.pgp Description: PGP signature
Bug#320627: crash w/ xpdf
> #0 0x0fcf5c40 in kill () from /lib/libc.so.6
> No symbol table info available.
> #1 0x0fcf5a08 in raise () from /lib/libc.so.6
> No symbol table info available.
> #2 0x0fcf7140 in abort () from /lib/libc.so.6
> No symbol table info available.
> #3 0x1045ec7c in ddxGiveUp () at xf86Init.c:1264
> i = 1
> #4 0x1045edfc in AbortDDX () at xf86Init.c:1319
> i = 1
> #5 0x105907c0 in AbortServer () at log.c:395
> No locals.
> #6 0x10590cf8 in FatalError (
> f=0x10ccb210 "Caught signal %d. Server aborting\n") at log.c:541
> args = {{gpr = 2 '\002', fpr = 0 '\0', reserved = 51740,
> overflow_arg_area = 0x7f8cc0b8, reg_save_area = 0x7f8cc028}}
> beenhere = 1
> #7 0x104883b8 in xf86SigHandler (signo=11) at xf86Events.c:1294
> No locals.
> #8
> No symbol table info available.
> Cannot access memory at address 0x304
Looks like a stack breakage caused a segfault.
Maybe it would be useful to run same xpdf throurg X protocol monitor (xmon
package), to see which request is causing the crash.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Ok to mention ubuntu versions inside Debian archive?
> Package: xserver-xorg > ... > Version: 1:7.0.0 > ... > Pre-Depends: x11-common (>= 7.0.0-0ubuntu3) Is this considered OK these days? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Extended Window Manager Hints specification ?
Hello. Could someone please help me to get a copy of Extended Window Manager Hints specification (that is, the specification how newer window manares such as kwin communicate with other X clients) ? The only URL I found is http://www.freedesktop.org/standards/wm-spec.html, but www.freedesktop.org seems to be either permanently down or unreachable from my location. Thank you.
ATI rage 128
Seems that with current X packages "ati" driver with ATI rage 128 card works much better (e.g. no garbage on screen) with Option "XaaNoSolidHorVertLine" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ATI rage 128
> used to have the same problem with 4.x,check out the 4.2 snapshots > deb http://people.debian.org/~branden/ sid/$(ARCH)/ Thank you. This is not needed here. Woody 4.1 packages work well. so no need to install unstable stuff on production workstation. Just the mentioned option should be added. This seem not to impact perfarmance noticably. I posted this to the list because someone may need this information. > > Jeremy > > On Monday 29 July 2002 3:15 am, Nikita V. Youshchenko wrote: > > Seems that with current X packages "ati" driver with ATI rage 128 card > > works much better (e.g. no garbage on screen) with > > > > Option "XaaNoSolidHorVertLine"
Setting up an X terminal: have to install tons of unneeded packages
Hello. I wanted to set up an X terminal (old Pentium 100) that will connect to remote xdm, and use remote xfs. I thought that the only X packages I need for the terminal are xfree86-common, xserver-common and xserver-xfree86. But I wanted to configure the X terminal keyboard using xkb (as I usually do on workstation). To do so, /etc/X11/xkb/* files are needed. But those are in xlibs package, and xkbcomp program (used by X server on startup to compile xkb keymap) is in xbase-clients package. And xbase-clients depends on 5 more packages (including huge xlibmesa3). All those are completely uneeded on an X terminal that never should run any local apps. Maybe /etc/X11/xkb stuff should be moved to xserver-common or xfree86-common? P.S. Yes I know it is possible to setup X terminal keyboard by running xkbcomp from Xsetup on server side, but I believe it is ugly.
Re: [desktop] Unix configuration nightmare
> They. Will. Not. Read. Maybe there will be somewhat less complains from those who don't read, if debconf stuff will calculate and store a checksum of autogenerated part of the file, and later don't touch it (or give extra warnings before touching) if the checksum does not match.
Running 2 X font servers
Hello. I really need to run 2 font server processes with different configuration on the same server. One should provide only small fonts for extremely slow clients that work too slow if get iso10646 fonts, and another should provide all available fonts for clients that cat handle them well. Currently I can't find any way to do that other than starting second xfs manually. I tried to start both from /etc/init.d/xfs, but this seems to lead to problems because PID file /var/run/xfs.pid seems to be hardcoded. The following code in /etc/init.d/xfs ... case "$1" in start) echo -n "Starting X font server: xfs" start-stop-daemon --start --quiet $SSD_ARGS -- -daemon || echo -n " already running" mv /var/run/xfs.pid /var/run/xfs.pid.save /usr/X11R6/bin/xfs -daemon -port 7101 -config /etc/X11/fs/config.nounicode mv /var/run/xfs.pid /var/run/xfs.nounicode.pid mv /var/run/xfs.pid.save /var/run/xfs.pid echo "." ... results into only one xfs running. Why?.. I tried make a copy of /etc/init.d/xfs to start second xfs in the way similar to first xfs, but I don't know how to call start-stop-daemon in this case. What is the correct way to solve the situation?
Re: Running 2 X font servers
> > > What is the correct way to solve the situation? > > Use xfs-xtt or xfstt for the second server? Hmm... How stable are those font servers? Font server stop or crash is very bad because not all X servers survive after disconnect from font server - they often hang or crash. Users don't like this for some reason - it's strange but it is a fact :-). Currently I run xfs from woody package while rest X packages are from sid. Sid's xfs (from XFree 4.2.1) crashed twice for me. (But I can't reproduce the crash reliably, so bug report on this will be useless). Can those font servers provide both pcf and tt fonts? When I will have to reboot the server next time, I will try the same /etc/init.d/xfs as in my previous mail, but with "sleep 2" inserted after starting first xfs. Maybe it will work. Can't test now because can't stop running server. If this will not help, maybe I will try other font servers... But it seems that the best way is to fix xfs to accept command line argument for pid file path. I guess that is pid file conflict will be resolved, 2 xfs processes can be started just with 2 start-stop-daemon calls.
Bug#167448: libxaw7: A bug in Xaw/StripChart.c causes incorrect scale lines in xload window
Package: libxaw7
Version: 4.2.1-3
Severity: normal
Tags: patch
Recently I tried to run xload on a high loaded server (load was more
than 10), and discovered that if window size is rather small, scale
lines are drawn incorrectly (upper than needed).
This is caused by a bug in Xaw/StripChart.c.
It draws lines with fixed integer steps. Than means that if window
height is 39 pixels, and 10 lines should be drawn to split view into 11
equal parts, lines will be drawn at 3, 6, 9, ,.., 30. So the bottom part
height will be 9 pixels while other parts height will be 2 pixels.
A patch to fix this is below. When applied, it makes part heights differ
no more than by 1 pixel.
Screenshots are at http://zigzag.lvk.cs.msu.su/~nikita/xload.png.
The top window is xload linked against patched libXaw, the bottom window
is xload linked against original libXaw.
--- StripChart.c.orig Fri Dec 14 22:54:44 2001
+++ StripChart.cSat Nov 2 17:26:15 2002
@@ -375,7 +375,7 @@
static int
repaint_window(StripChartWidget w, int left, int width)
{
-int i, j;
+int i, j, k;
int next = w->strip_chart.interval;
int scale = w->strip_chart.scale;
int scalewidth = 0;
@@ -420,8 +420,10 @@
}
/* Draw graph reference lines */
+ k = XtHeight(w) % w->strip_chart.scale;
for (i = 1; i < w->strip_chart.scale; i++) {
- j = i * ((int)XtHeight(w) / w->strip_chart.scale);
+ j = i * (XtHeight(w) / w->strip_chart.scale) +
+ ((i * k + w->strip_chart.scale/2) /
w->strip_chart.scale);
XDrawLine(dpy, win, w->strip_chart.hiGC, left, j,
scalewidth, j);
}
}
@@ -443,7 +445,7 @@
MoveChart(StripChartWidget w, Bool blit)
{
double old_max;
-int left, i, j;
+int left, i, j, k;
int next = w->strip_chart.interval;
if (!XtIsRealized((Widget)w))
@@ -492,8 +494,10 @@
/* Draw graph reference lines */
left = j;
+k = XtHeight(w) % w->strip_chart.scale;
for (i = 1; i < w->strip_chart.scale; i++) {
- j = i * (XtHeight(w) / w->strip_chart.scale);
+ j = i * (XtHeight(w) / w->strip_chart.scale) +
+ ((i * k + w->strip_chart.scale/2) / w->strip_chart.scale);
XDrawLine(XtDisplay((Widget)w), XtWindow((Widget)w),
w->strip_chart.hiGC, left, j, XtWidth(w), j);
}
@@ -554,7 +558,7 @@
StripChartWidget w = (StripChartWidget)widget;
XPoint *points;
Cardinal size;
-int i;
+int i, k;
if (w->strip_chart.scale <= 1) {
XtFree((char *)w->strip_chart.points);
@@ -569,8 +573,12 @@
/* Draw graph reference lines into clip mask */
+k = XtHeight(w) % w->strip_chart.scale;
for (i = 1; i < w->strip_chart.scale; i++) {
points[i - 1].x = 0;
- points[i - 1].y = XtHeight(w) / w->strip_chart.scale;
+ points[i - 1].y = i * (XtHeight(w) / w->strip_chart.scale) +
+ ((i * k + w->strip_chart.scale/2) / w->strip_chart.scale);
}
+for (i = w->strip_chart.scale - 1; i > 1; i--)
+ points[i - 1].y -= points[i - 2].y;
}
-- System Information:
Debian Release: 3.0
Architecture: i386
Kernel: Linux sercond 2.4.19 #1 óÂÔ óÅÎ 28 15:05:51 MSD 2002 i686
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R
Versions of packages libxaw7 depends on:
ii libc6 2.3.1-3GNU C Library: Shared libraries an
ii xlibs 4.2.1-3X Window System client libraries
-- no debconf information
Bug#167605: xfs should have configurable pid file
Package: xfs
Version: 4.2.1-3
Severity: normal
Tags: patch
In current xfs package, pid file is hardcoded to /var/run/xfs.pid.
Hardcoded pid file leads to problems if more than one font server should
run (e.g. one providing unicode fonts for fast clients, and another one
not providing unicode fonts for slow clients).
The following patch adds -pid option for xfs that may be used to change
pid file.
diff -ur xfs.orig/os/utils.c xfs/os/utils.c
--- xfs.orig/os/utils.c Mon Nov 4 00:18:04 2002
+++ xfs/os/utils.c Sun Nov 3 23:56:29 2002
@@ -219,7 +219,7 @@
static void
usage(void)
{
-fprintf(stderr, "usage: %s [-config config_file] [-port tcp_port]
[-droppriv] [-daemon] [-nodaemon] [-user user_name]\n",
+fprintf(stderr, "usage: %s [-config config_file] [-port tcp_port]
[-droppriv] [-daemon] [-nodaemon] [-user user_name] [-pid pid_file]\n",
progname);
exit(1);
}
@@ -338,6 +338,11 @@
} else if (!strcmp(argv[i], "-cf") || !strcmp(argv[i], "-config")) {
if (argv[i + 1])
configfilename = argv[++i];
+ else
+ usage();
+ } else if (!strcmp(argv[i], "-pid")) {
+ if (argv[i + 1])
+ pidFile = argv[++i];
else
usage();
}
diff -ur xfs.orig/xfs.man xfs/xfs.man
--- xfs.orig/xfs.manFri Dec 14 23:01:32 2001
+++ xfs/xfs.man Mon Nov 4 00:10:33 2002
@@ -49,6 +49,7 @@
[\-nodaemon]
[\-port \fItcp_port\fP]
[\-user \fIusername\fP]
+[\-pid \fIpid_file\fP]
.SH DESCRIPTION
.PP
.I Xfs
@@ -99,6 +100,10 @@
This is equivalent to
.B \-droppriv
except that xfs will run as user \fIusername\fR.
+.TP 8
+.B \-pid pid_file
+Save daemon process id into \fIpid_file\fR, instead of default
+\fI/var/run/xfs.pid\fR.
.SH "SIGNALS"
.TP 8
.I SIGTERM
-- System Information:
Debian Release: 3.0
Architecture: i386
Kernel: Linux sercond 2.4.19 #1 óÂÔ óÅÎ 28 15:05:51 MSD 2002 i686
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R
Versions of packages xfs depends on:
ii debconf 1.2.14 Debian configuration management sy
ii libc6 2.3.1-3GNU C Library: Shared libraries an
ii zlib1g1:1.1.4-6 compression library - runtime
-- debconf information:
* xfs/default_100dpi:
* xfs/default_nolisten_tcp:
Bug#168791: xfs: A fix for xfs segfault
Package: xfs
Version: 4.2.1-3
Severity: important
Tags: patch
After upgrade to Xfree 4.2.1, several times we experienced xfs crashes.
(quite bad, because it causes several user sessions on terminals to crash)
At last one of our users found an reprodusable sequence of actions to
crash xfs. So I've tracked the bug.
It dereferences a NULL pointer in xc/lib/font/fontfile/fontenc.c
The following patch fixes the problem:
--- fontenc.c.orig Tue Nov 12 17:11:37 2002
+++ fontenc.c Tue Nov 12 17:25:29 2002
@@ -744,7 +744,7 @@
/* Check whether the name is already known for this encoding */
if(strcasecmp(encoding->name, encoding_name) == 0) {
found = 1;
-} else {
+} else if (encoding->aliases) {
for(alias=encoding->aliases; *alias; alias++)
if(!strcasecmp(*alias, encoding_name)) {
found = 1;
@@ -763,17 +763,21 @@
if(new_name == NULL)
return NULL;
strcpy(new_name, encoding_name);
-for(alias = encoding->aliases; *alias; alias++)
-numaliases++;
+ if (encoding->aliases) {
+for(alias = encoding->aliases; *alias; alias++)
+numaliases++;
+ }
new_aliases = (char**)xalloc((numaliases+2)*sizeof(char*));
if(new_aliases == NULL) {
xfree(new_name);
return NULL;
}
-memcpy(new_aliases, encoding->aliases, numaliases*sizeof(char*));
+if (encoding->aliases) {
+ memcpy(new_aliases, encoding->aliases,
numaliases*sizeof(char*));
+ xfree(encoding->aliases);
+ }
new_aliases[numaliases] = new_name;
new_aliases[numaliases+1] = NULL;
-xfree(encoding->aliases);
encoding->aliases = new_aliases;
}
-- System Information:
Debian Release: 3.0
Architecture: i386
Kernel: Linux zigzag 2.4.19 #1 óÒÄ îÏÑ 6 17:54:30 MSK 2002 i686
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R
Versions of packages xfs depends on:
ii debconf 1.2.14 Debian configuration management sy
ii libc6 2.3.1-3GNU C Library: Shared libraries an
ii zlib1g1:1.1.4-1 compression library - runtime
-- debconf information:
* xfs/default_100dpi:
* xfs/default_nolisten_tcp:
Bug#366355: This may be caused by incorrect display number selection
Looks like I've faced something similar to this bug, and seems that it is caused by incorrect choice of dispaly number by remote sshd. Look: [EMAIL PROTECTED]:~> ssh -X sercond No mail. [EMAIL PROTECTED]:~> echo $DISPLAY localhost:10.0 [EMAIL PROTECTED]:~> xterm xterm Xt error: Can't open display: localhost:10.0 However, at this point there already exists an ssh connection to 'sercond' host from different host, with X11 forwarding enabled, that uses display 10! [EMAIL PROTECTED]:~> ssh -x sercond No mail. [EMAIL PROTECTED]:~> echo $DISPLAY [EMAIL PROTECTED]:~> sudo netstat -lapn | grep 6010 tcp0 0 127.0.0.1:6010 127.0.0.1:57566 ESTABLISHED1096/sshd: [EMAIL PROTECTED] tcp0 0 127.0.0.1:57566 127.0.0.1:6010 ESTABLISHED1099/kmix So for unknown reason, new ssh connection to sercond does not detect that :0 is already in use there. So running X client actually tries to connect to different display, and that connections is naturaly rejected. If I connect one more connection with -X from 'bliss' to 'sercond', while keeping older -X connection active, new connection gets dispaly 11, and X forwarding works. I was able to reproduce problem from clear. - shutdown all ssh connections - try to connect from 'bliss' to 'sercond', X11 forwadring works - shutdown connection from 'bliss' to 'sercond' - set up connection from 'blacky' to 'sercond' - try to connect rom 'bliss' to 'sercond' once more - X11 forwarding does not work, because it tries to use display 10 on 'sercond' that is already occupied by connection from 'blacky'. blacky has: ii libx11-6 6.9.0.dfsg.1-6 ii openssh-client 4.2p1-8 ii openssh-server 4.2p1-8 bliss has: ii libx11-6 1.0.0-6 ii openssh-client 4.2p1-8 ii openssh-server 4.2p1-8 sercond has: ii libx11-6 6.9.0.dfsg.1-4 ii openssh-client 4.2p1-8 ii openssh-server 4.2p1-8 pgpadwoahmXGd.pgp Description: PGP signature
Re: Bug#372856: krandrtray does NOT correctly switch resolution on my setup
While trying to add xrandr support to Xvnc, I faced a bug in xrandr implementation in XFree 4.x; maybe current Xorg also has it? Bug is that xrandr stores the moment of last switch as 64-bit value. Then, in 'get configuration' request it sends this time to client as 32-bit value. In 'set configuration' request clents should return same value to the server. Idea is to check situation when other client has changed configuration since this client last read it. Problem is with timestamp compare in implementation of 'set configuration' request. It compares 64 bit values; before that, it converts 32 bit value got from client to 64 bit value by guessing the 'nearest' 64bit value (see ClentTimeToServerTime() routine). In practice this may result in comparison failure because of difference in higher word. This happens at least in two cases: - if enough ime (about a month) passed since last configuration (or server startup) - [much more probable] if system time went backwards at some moment (ntp? date -s?), X server manually increases higher word of it's server time to avoid server time going backwards. If this problem raises, nor xrandr -s, not krandrtray, nor any other xrandr client is able to switch configuration until X server restarts. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redirect Xsession error to syslogd
> Hi, > > I'd like all errors from my xsession to go to the syslogd daemon instead > of ~/.xsession-error. > > Can that be easily done? You may use 'logger' for that; see man logger for details. E.g. find 'exec >>"$ERRFILE" 2>&1' in /etc/X11/Xsession, remove it, and move entire script into ( ... ) 2>&1 | logger construction. Or something similar. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Extended Window Manager Hints specification ?
Hello. Could someone please help me to get a copy of Extended Window Manager Hints specification (that is, the specification how newer window manares such as kwin communicate with other X clients) ? The only URL I found is http://www.freedesktop.org/standards/wm-spec.html, but www.freedesktop.org seems to be either permanently down or unreachable from my location. Thank you. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Monitoring for keyboard event.
> Does anybody know how it is possible to catch keyboard events, > regardless of the pointer position? > > The only way I found is by using XQueryTree for RootWindow, which builds > an hierarchy of all existing windows and then XSelectInput with > KeyPressMask | SubstructureNotifyMask for every window. This seems to be > unreliable: the root window on IRIX as well as some new windows do not > report events. Is there a way to directly catch all keyboard events? Maybe a passive grab on the root window, and AllowEvents(Replay) after processing? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why XFree86 4.2 Isn't in Woody
Seems that 4.1.0-16 fixed at last the old problem with garbage-on-screen in kicker and in nedit scrollbars on r128 card. Great work ! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
