Bug#166413: mga driver doesn't set gamma on second screen
On Mon, Oct 28, 2002 at 11:05:07PM +0100, Michel Dänzer wrote: On Mon, 2002-10-28 at 21:29, [EMAIL PROTECTED] wrote: * If someone has a Matrox card that *can* set the gamma on the second head, file a separate report. Brett has a Matrox MGA G400 AGP rev 130. That is the only model of card that matters for this report. Umm, actually I've got a matrox G450 - their similar, but slightly different. Looks like linux's pci database needs to be updated, and lspci on my box returns: 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 82) But I know for a fact I've got a g450 (at least that's what the box says, and what windows reports). I'm running 2.4.18 so maybe this is reported correctly in a newer kernel. AFIK the g400 isn't even a dual-head card. G450 is the card, which uses a G400 chip for the primary head, and I think the so called Maven chipset for the secondary. No, i think all G400 boards used a maven chip for the second head, well, actually it is not a separate chip, but included in the G400. The G450 was a G400 with a smaller process and which used a DDR memory bus instead of the dual mono directional SDR memeory bus of the G400. I think it was more or less the same, just cheaper for matrox to manufacture. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [desktop] Unix configuration nightmare
Branden Robinson [EMAIL PROTECTED] wrote: [...] * hates and fears text config files and will not touch them * will read and edit a text config file But there is such a third group: * will edit a text config file, but only given very precise and explicit instructions -- will not read manpages, will not read the config file itself, has tunnel vision, will only take action on suggestions like right after the line that says Driver mga in your XFree config file[sic], add a line that says Option WhizzBang and you'll be able to use the special Tomb Raider hack that let you play Lara Croft without any clothes on, and adds lots of mirrors to the level maps ROTFL This one not only sent me rolling on the floor but managed to amuse my sister, too, although she'snot interested in computer stuff. Please keep it up. So, like I said, it's my fault. I didn't think many such people existed. They do, and because they are numerous it's my responsibility as a Debian package maintainer to accomodate their needs. What you want to do will still be possible, but you'll have to use interdiff or something. An easy thing will be made hard -- or at least tedious -- so that a different easy thing can be made even easier than it was, because even easy was too hard for some people. We had the same problem with debconfization of exim v4 but could not use your original workaround to allow user-modifications, because you cannot have sections two times in exim.conf. That's when I came up with the scheme of saving the results of the debconf-questions to a simple parseable variable=value file, and automatically generating the final configuration-file in /var/lib/exim4 from this file and the dpkg-conffile /etc/exim4/exim4.conf.template with a simple script update-exim4.conf(8). The template file is a normal exim.conf file with additional magic-strings that are replaced by the update script with the values from the debconf-results file. | hostlist relay_from_hosts = 127.0.0.1 : 1 : DEBCONFrelay_netsDEBCONF | qualify_domain = DEBCONFvisiblenameDEBCONF | acl_smtp_rcpt = acl_check_rcpt | never_users = root Of course the user can put a file without the magic-strings in /etc/exim4/exim4.conf.template and it'll be used unmodified. This is a variation of your original system with some added value: - correct debconf support, the file that is managed with debconf is simply parseable, so user modifications outside debconf are easy to preserve. - /etc/exim4/exim4.conf.template has dpkg conffile managment, user modifications are easy to preserve. - everthing in /etc/ can be edited. Of course this scheme is bound to fail if our little tomb-raider friend starts editing /var/lib/exim4/exim4.conf directly but I hope that he simply won't find it because it is hidden in a non-standard location. And I am not sure if this might work X too, XF86Config has a very complex structure. cu andreas -- Hey, da ist ein Ballonautomat auf der Toilette! Unofficial _Debian-packages_ of latest unstable _tin_ http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/ -- 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#167009: Additional details
Hello, I tried downgrading to 4.2.1-1 (from 4.2.1-3) to see if that would improve matters. It apparently did not, although after one sleep my mouse alone remained responsive. However, I discovered that the machine was still listening on its airport interface and was able to log in and do some more debugging. It turns out that when X throws one of these fits, it's spinlocking. Running strace on it yields this sort of result, repeated over and over: ioctl(6, 0x20006444, 0) = -1 EBUSY (Device or resource busy) ioctl(6, 0x20006444, 0) = -1 EBUSY (Device or resource busy) --- SIGALRM (Alarm clock) --- ioctl(6, 0x20006444, 0) = -1 EBUSY (Device or resource busy) ioctl(6, 0x20006444, 0) = -1 EBUSY (Device or resource busy) --- SIGALRM (Alarm clock) --- ioctl(6, 0x20006444, 0) = -1 EBUSY (Device or resource busy) ioctl(6, 0x20006444, 0) = -1 EBUSY (Device or resource busy) ioctl(6, 0x20006444, 0) = -1 EBUSY (Device or resource busy) Now, looking at the X server process, I see that fd 6 is attached to /dev/dri/card0. Maybe a clue. I checked my kdm.log, XFree86 log, and syslog, and noticed nothing out of the ordinary in any of them. The first two had not logged any data since the sleep/wakeup. Hope this can shed some light on the matter. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#166413: mga driver doesn't set gamma on second screen
On Mon, Oct 28, 2002 at 11:05:07PM +0100, Michel Dänzer wrote: On Mon, 2002-10-28 at 21:29, [EMAIL PROTECTED] wrote: * If someone has a Matrox card that *can* set the gamma on the second head, file a separate report. Brett has a Matrox MGA G400 AGP rev 130. That is the only model of card that matters for this report. Umm, actually I've got a matrox G450 - their similar, but slightly different. Looks like linux's pci database needs to be updated, and lspci on my box returns: 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 82) But I know for a fact I've got a g450 (at least that's what the box says, and what windows reports). I'm running 2.4.18 so maybe this is reported correctly in a newer kernel. AFIK the g400 isn't even a dual-head card. G450 is the card, which uses a G400 chip for the primary head, and I think the so called Maven chipset for the secondary. No, i think all G400 boards used a maven chip for the second head, well, actually it is not a separate chip, but included in the G400. The G450 was a G400 with a smaller process and which used a DDR memory bus instead of the dual mono directional SDR memeory bus of the G400. I think it was more or less the same, just cheaper for matrox to manufacture. Friendly, Sven Luther
Re: [desktop] Unix configuration nightmare
Branden Robinson [EMAIL PROTECTED] wrote: [...] * hates and fears text config files and will not touch them * will read and edit a text config file But there is such a third group: * will edit a text config file, but only given very precise and explicit instructions -- will not read manpages, will not read the config file itself, has tunnel vision, will only take action on suggestions like right after the line that says Driver mga in your XFree config file[sic], add a line that says Option WhizzBang and you'll be able to use the special Tomb Raider hack that let you play Lara Croft without any clothes on, and adds lots of mirrors to the level maps ROTFL This one not only sent me rolling on the floor but managed to amuse my sister, too, although she'snot interested in computer stuff. Please keep it up. So, like I said, it's my fault. I didn't think many such people existed. They do, and because they are numerous it's my responsibility as a Debian package maintainer to accomodate their needs. What you want to do will still be possible, but you'll have to use interdiff or something. An easy thing will be made hard -- or at least tedious -- so that a different easy thing can be made even easier than it was, because even easy was too hard for some people. We had the same problem with debconfization of exim v4 but could not use your original workaround to allow user-modifications, because you cannot have sections two times in exim.conf. That's when I came up with the scheme of saving the results of the debconf-questions to a simple parseable variable=value file, and automatically generating the final configuration-file in /var/lib/exim4 from this file and the dpkg-conffile /etc/exim4/exim4.conf.template with a simple script update-exim4.conf(8). The template file is a normal exim.conf file with additional magic-strings that are replaced by the update script with the values from the debconf-results file. | hostlist relay_from_hosts = 127.0.0.1 : 1 : DEBCONFrelay_netsDEBCONF | qualify_domain = DEBCONFvisiblenameDEBCONF | acl_smtp_rcpt = acl_check_rcpt | never_users = root Of course the user can put a file without the magic-strings in /etc/exim4/exim4.conf.template and it'll be used unmodified. This is a variation of your original system with some added value: - correct debconf support, the file that is managed with debconf is simply parseable, so user modifications outside debconf are easy to preserve. - /etc/exim4/exim4.conf.template has dpkg conffile managment, user modifications are easy to preserve. - everthing in /etc/ can be edited. Of course this scheme is bound to fail if our little tomb-raider friend starts editing /var/lib/exim4/exim4.conf directly but I hope that he simply won't find it because it is hidden in a non-standard location. And I am not sure if this might work X too, XF86Config has a very complex structure. cu andreas -- Hey, da ist ein Ballonautomat auf der Toilette! Unofficial _Debian-packages_ of latest unstable _tin_ http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/
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
On Die, 2002-10-29 at 15:57, Nikita V. Youshchenko wrote: 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. [...] What is the correct way to solve the situation? Use xfs-xtt or xfstt for the second server? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast
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#167009: Additional details
Hello, I tried downgrading to 4.2.1-1 (from 4.2.1-3) to see if that would improve matters. It apparently did not, although after one sleep my mouse alone remained responsive. However, I discovered that the machine was still listening on its airport interface and was able to log in and do some more debugging. It turns out that when X throws one of these fits, it's spinlocking. Running strace on it yields this sort of result, repeated over and over: ioctl(6, 0x20006444, 0) = -1 EBUSY (Device or resource busy) ioctl(6, 0x20006444, 0) = -1 EBUSY (Device or resource busy) --- SIGALRM (Alarm clock) --- ioctl(6, 0x20006444, 0) = -1 EBUSY (Device or resource busy) ioctl(6, 0x20006444, 0) = -1 EBUSY (Device or resource busy) --- SIGALRM (Alarm clock) --- ioctl(6, 0x20006444, 0) = -1 EBUSY (Device or resource busy) ioctl(6, 0x20006444, 0) = -1 EBUSY (Device or resource busy) ioctl(6, 0x20006444, 0) = -1 EBUSY (Device or resource busy) Now, looking at the X server process, I see that fd 6 is attached to /dev/dri/card0. Maybe a clue. I checked my kdm.log, XFree86 log, and syslog, and noticed nothing out of the ordinary in any of them. The first two had not logged any data since the sleep/wakeup. Hope this can shed some light on the matter. -- John
