Bug#524273: (no subject)
severity 524273 grave thanks I have the same problem. CCSM 0.8.2-1 is completely unusable, presumably for everyone, because of this bug. Traceback (most recent call last): File "/usr/lib/pymodules/python2.5/ccm/Pages.py", line 1302, in ShowPlugin pluginPage = PluginPage(plugin) File "/usr/lib/pymodules/python2.5/ccm/Pages.py", line 125, in __init__ sortedGroups = sorted(plugin.Groups.items(), key=GroupIndexKeyFunc) File "/usr/lib/pymodules/python2.5/ccm/Utils.py", line 374, in GroupIndexKeyFunc return item[1][0] KeyError: 0 signature.asc Description: This is a digitally signed message part.
Bug#225762: xserver-xfree86: Another magic key sequence to restore video mode etc.
Ah, good. I guess all that's left is to restore the video mode, which isn't really altogether important given the ability to release grabs, but it'd still be nice. Alex. pgpzHDFIDUqao.pgp Description: signature
Bug#225762: xserver-xfree86: Another magic key sequence to restore video mode etc.
Package: xserver-xfree86 Version: 4.2.1-14 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sometimes, an X client will screw up various things on the server, like grabbing the mouse without releasing it, changing the video mode and not changing it back, and so forth. While it would be useful for the server to clean up after such a client if it disconnects, it would be useful in any case to have another magic button (along the lines of ctrl-alt-backspace) to forcibly restore sanity. In particular, it should: * Release the mouse cursor if it was grabbed. * Restore the mouse cursor bitmap/whatever to the standard arrow cursor. * Release the keyboard. * Restore the video mode to what it was when the server was started. Perhaps there are other necessary cleanups I forgot, but you get the idea. It would also be nice to have another magic key combination that starts an arbitrary program as specified in the configuration file, regardless of what any of the running X clients might think of that. Then this program could provide some functionality akin to the window one gets when pushing ctrl-alt-delete on Microsoft Windows 2000, or the Force Quit window on Mac OS X. The addition of such a feature should go a long way toward removing the need to ssh in to kill the X server if some application goes awry. - -- Package-specific info: 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 04) 01:00.0 Class 0300: 102b:0525 (rev 04) Section "ServerLayout" Identifier "Default Layout" Screen 0 "Hi-Res Screen" 0 0 InputDevice"Mouse1" "CorePointer" InputDevice"Keyboard1" "CoreKeyboard" EndSection Section "ServerFlags" Option "BlankTime" "off" Option "StandbyTime" "10" Option "SuspendTime" "off" Option "OffTime" "30" EndSection Section "Files" RgbPath "/usr/X11R6/lib/X11/rgb" FontPath "/usr/X11R6/lib/X11/fonts/local/" FontPath "/usr/X11R6/lib/X11/fonts/misc/" FontPath "/usr/X11R6/lib/X11/fonts/75dpi/:unscaled" FontPath "/usr/X11R6/lib/X11/fonts/100dpi/:unscaled" FontPath "/usr/X11R6/lib/X11/fonts/Type1/" FontPath "/usr/X11R6/lib/X11/fonts/Speedo/" FontPath "/usr/X11R6/lib/X11/fonts/75dpi/" FontPath "/usr/X11R6/lib/X11/fonts/100dpi/" FontPath "/usr/X11R6/lib/X11/fonts/TrueType/" FontPath "/usr/X11R6/lib/X11/fonts/freefont/" FontPath "/var/lib/defoma/x-ttcidfont-conf.d/dirs/CID" FontPath "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" ModulePath "/usr/X11R6/lib/modules" EndSection Section "Module" Load "dbe" SubSection "extmod" Option "omit xfree86-dga" EndSubSection Load "type1" Load "freetype" Load "glx" Load "dri" EndSection Section "InputDevice" Identifier "Keyboard1" Driver "Keyboard" Option "AutoRepeat" "500 30" Option "XkbRules" "xfree86" Option "XkbModel" "pc104" Option "XkbLayout" "us" Option "XkbCompat" "" EndSection Section "InputDevice" Identifier "Mouse1" Driver "mouse" Option "Protocol" "ExplorerPS/2" Option "Device" "/dev/mouse" Option "Buttons" "7" Option "ZAxisMapping" "6 7" #Option "Emulate3Buttons" EndSection Section "Monitor" Identifier "ViewSonic A70" HorizSync30 - 70 VertRefresh 50 - 180 DisplaySize 325 243 Option "DPMS" EndSection Section "Device" Identifier "3Dfx Voodoo Banshee 16MB PCI" Driver "tdfx" EndSection Section "Device" Identifier "Matrox G400" Driver "mga" Option "UseFBDev" "off" Option "HWCursor" "on" EndSection Section "Screen" Identifier "Hi-Res Screen" Device "Matrox G400" Monitor"ViewSonic A70" DefaultDepth 24 SubSection "Display" Depth 24 Modes "1152x864" "1024x768" "800x600" "640x480" "640x400" "512x384" "400x300" "320x240" "320x200" EndSubSection EndSection Section "Screen" Identifier "Normal Screen" Device "Matrox G400" Monitor"ViewSonic A70" DefaultDepth24 SubSection "Display" Depth 24 Modes "1024x768" "800x600" "640x480" "640x400" "512x384" "400x300" "320x240" "320x200" EndSubSection EndSection Section "DRI" Mode 0666 EndSection This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to XFree86@XFree86.Org and patches submitted to [EMAIL PROTECTED] Before reporting bugs in pre-release versions, please check th
Re: Debian DRI CVS packages ready for testing.
On Mon, 26 Mar 2001 23:36:57 -0500 "Zephaniah E\. Hull" <[EMAIL PROTECTED]> wrote: > The subject says most of it, the packages are at > http://master.debian.org/~warp/, they are /not/ apt-able right now, I'll > sort that out tomorrow. OK. Please post to this list and say when it's aptable. > They are still very much in testing, follow the depends on the packages, > and, err, you may have to do an ldconfig after installing xlibmesa3-dri, > I forgot that in the postinst and I'm going to sleep now, again, I'll > deal with it tomorrow. > > The packages are against current unstable, and seem to work for me. > > Please do NOT build debian packages with these packages installed at > this time, also please report all packaging issues to me, if you're not > sure a bug is purely in the DRI code also report it to me. > > Note that this does NOT include the kernel DRM modules, the ones in > 2.4.2+ seem to work with the current DRI CVS, and thus these packages. > > Once I have a few more things pounded out I will likely have a cron job > build them every 24 hours, eventually these packages will likely go into > unstable, though likely only being built once or twice a week at that > point. How soon can I expect (hope for) that to happen? Regards, Alex.
Re: Debian DRI CVS packages ready for testing.
On Mon, 26 Mar 2001 23:36:57 -0500 "Zephaniah E\. Hull" <[EMAIL PROTECTED]> wrote: > The subject says most of it, the packages are at > http://master.debian.org/~warp/, they are /not/ apt-able right now, I'll > sort that out tomorrow. OK. Please post to this list and say when it's aptable. > They are still very much in testing, follow the depends on the packages, > and, err, you may have to do an ldconfig after installing xlibmesa3-dri, > I forgot that in the postinst and I'm going to sleep now, again, I'll > deal with it tomorrow. > > The packages are against current unstable, and seem to work for me. > > Please do NOT build debian packages with these packages installed at > this time, also please report all packaging issues to me, if you're not > sure a bug is purely in the DRI code also report it to me. > > Note that this does NOT include the kernel DRM modules, the ones in > 2.4.2+ seem to work with the current DRI CVS, and thus these packages. > > Once I have a few more things pounded out I will likely have a cron job > build them every 24 hours, eventually these packages will likely go into > unstable, though likely only being built once or twice a week at that > point. How soon can I expect (hope for) that to happen? Regards, Alex. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help needed, TDFX [Re: Release-critical Bugreport for March 23, 2001]
On Sat, 24 Mar 2001 14:54:35 -0600 Gordon Sadler <[EMAIL PROTECTED]> wrote: > On Sat, Mar 24, 2001 at 03:20:09PM -0500, Branden Robinson wrote: > > On Sat, Mar 24, 2001 at 02:48:23PM -0500, Zephaniah E. Hull wrote: > > > X4 no longer knows about glide2 > > > > That's not precisely true. xfree86 Build-Depends on libglide2-dev for a > > reason; to build the "glide" driver which gives you a *2D* X environment on > > Voodoo Graphics and Voodoo2 cards. > > > You mean to say a Voodoo2 graphics card that is sold/marketed/used as a > 3D only chipset, can be used under X4 as a '2D' card? With no other > VESA/VGA card available? > > If that's true that's great, I have a V2 sitting here doing nothing, > don't play many games under Linux -). But I could use it build another > computer that's missing a graphics card, and use gdm/xdm/kdm to boot > straight to X4? The Voodoo Graphics and Voodoo2 chips are designed mainly for 3D, but they are also capable of 2D. The reason that they aren't marketed for this is that their 2D performance is exceedingly slow (ie, unaccelerated) compared to cards that are actually designed to do 2D. The 2D capabilities of these cards is mainly intended for drawing in-game 2D displays, such as heads-up displays, status bars, etc. Use the `glide' driver in XFree86 4.x to use your Voodoo2 as the only video card. Regards, Alex.
Re: Help needed, TDFX [Re: Release-critical Bugreport for March 23, 2001]
On Sat, 24 Mar 2001 14:54:35 -0600 Gordon Sadler <[EMAIL PROTECTED]> wrote: > On Sat, Mar 24, 2001 at 03:20:09PM -0500, Branden Robinson wrote: > > On Sat, Mar 24, 2001 at 02:48:23PM -0500, Zephaniah E. Hull wrote: > > > X4 no longer knows about glide2 > > > > That's not precisely true. xfree86 Build-Depends on libglide2-dev for a > > reason; to build the "glide" driver which gives you a *2D* X environment on > > Voodoo Graphics and Voodoo2 cards. > > > You mean to say a Voodoo2 graphics card that is sold/marketed/used as a > 3D only chipset, can be used under X4 as a '2D' card? With no other > VESA/VGA card available? > > If that's true that's great, I have a V2 sitting here doing nothing, > don't play many games under Linux -). But I could use it build another > computer that's missing a graphics card, and use gdm/xdm/kdm to boot > straight to X4? The Voodoo Graphics and Voodoo2 chips are designed mainly for 3D, but they are also capable of 2D. The reason that they aren't marketed for this is that their 2D performance is exceedingly slow (ie, unaccelerated) compared to cards that are actually designed to do 2D. The 2D capabilities of these cards is mainly intended for drawing in-game 2D displays, such as heads-up displays, status bars, etc. Use the `glide' driver in XFree86 4.x to use your Voodoo2 as the only video card. Regards, Alex. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help needed, TDFX [Re: Release-critical Bugreport for March 23, 2001]
On Sat, 24 Mar 2001 02:06:40 -0800 Joseph Carter <[EMAIL PROTECTED]> wrote: > On Fri, Mar 23, 2001 at 03:15:25PM -0800, Alexander Hvostov wrote: > > I have this problem too. After a while, X freezes while running _any_ OpenGL > > application. This means blender, GL screen savers, GL xmms plugins, etc. > > I'll assume you're running XFree4 since you didn't say otherwise. Correct. > X freezes like this for me quite frequently. Branden claimed it was a > kernel bug some months ago, but that was fixed and it still dies. A > number of things cause it, but I never knew DRI to be one of them. > Mozilla caused my uptimes to be measured in hours rather than weeks under > recent XFree4 packages. With my new card (ATI Radeon) it's changing video > modes (which anyone who has seen me work in X knows I spend 30% of my time > in 640x480 or lower due to unreadably small, aliased fonts in things like > Netscape..) > > The problem seems to be in short that damned near anything will cause X to > lock up and stop responding. A suggestion to make your life a little > easier is to renice XFree86 to 0. For some reason it gets -10 by default > amd that's just pleading for a lockup to down the box if you don't have a > convenient box to ssh in and fix it. Ouch. I only get trouble with DRI applications. X behaves quite nicely with anything else (shm, dga, or regular X). > > The only way to recover from this is to login to the machine over the > > network, > > kill -9 X, and restart it (which, in my case, is done by gdm). However, > > doing > > this causes the text mode console to become totally screwed up; attempting > > to > > switch to the console works except that the display is still in graphics > > mode > > (with whatever X drew on the screen). This display doesn't get repainted, > > since all the software (the kernel and X) thinks the display is in text > > mode, > > but it really isn't. Switching back to X works fine though (ie, it repaints > > the screen and otherwise behaves normally). > > You can fix this by using the framebuffer console for your card. Except > that most framebuffer drivers are not quite stable (like XFree4 it would > seem) and very slow. > > > > For this reason, I've disabled DRI on my system until this problem gets > > fixed. > > It would be nice to have it fixed, since applications like blender get > > really > > slow without it... > > > > My hardware is a Creative 3D Blaster Banshee. The chip is 3Dfx Voodoo > > Banshee, > > PCI revision 3, part/serial/whatever number CT6760, 16 MB SDRAM on-board. > > It's > > attached to PCI (as you might have guessed). > > > > Because the freezes seem totally unpredictable (except of course that a GL > > application is running at the time of the freeze), I find this bug difficult > > to reproduce. > > I can reproduce it with XawTV, Ctrl-Alt-Grey+, and any DRI app which uses > the VidMode extension. I can also do it with anything that creates shaped > windows frequently (the OSD plugin for XMMS for example or some window > manager themes) In short, it's really easy to get X to freeze. Again, I have no trouble with anything other than DRI. Since I've disabled DRI, X doesn't do anything out of the ordinary here. Regards, Alex.
Re: Help needed, TDFX [Re: Release-critical Bugreport for March 23, 2001]
On Fri, 23 Mar 2001 23:29:12 +0100 "Marcelo E. Magallon" <[EMAIL PROTECTED]> wrote: > >> BugScan reporter <[EMAIL PROTECTED]> writes: > > > Package: mesag3-glide2 (debian/main) > > Maintainer: Marcelo E. Magallon <[EMAIL PROTECTED]> > > 74471 Open GL xscreensavers cause X to hang with 3DFX cards. > > I need help with this bug, I can't test this as I don't have TDFX > hardware. I have this problem too. After a while, X freezes while running _any_ OpenGL application. This means blender, GL screen savers, GL xmms plugins, etc. The only way to recover from this is to login to the machine over the network, kill -9 X, and restart it (which, in my case, is done by gdm). However, doing this causes the text mode console to become totally screwed up; attempting to switch to the console works except that the display is still in graphics mode (with whatever X drew on the screen). This display doesn't get repainted, since all the software (the kernel and X) thinks the display is in text mode, but it really isn't. Switching back to X works fine though (ie, it repaints the screen and otherwise behaves normally). For this reason, I've disabled DRI on my system until this problem gets fixed. It would be nice to have it fixed, since applications like blender get really slow without it... My hardware is a Creative 3D Blaster Banshee. The chip is 3Dfx Voodoo Banshee, PCI revision 3, part/serial/whatever number CT6760, 16 MB SDRAM on-board. It's attached to PCI (as you might have guessed). Because the freezes seem totally unpredictable (except of course that a GL application is running at the time of the freeze), I find this bug difficult to reproduce. Regards, Alex.
Sawfish GNOME control center problem
Hi everyone, I seem to be having a problem with Sawfish's GNOME capplets: unlike all other capplets, Sawfish's capplets always require me to press "Try" before pressing "OK" to actually make the changes have any effect. Otherwise, they are silently ignored, as if I had pressed "Cancel". On all machines other than this one, the Sawfish capplets work in the expected manner; i.e., pressing "OK" makes the changes take effect. Any help in figuring out this problem out would be greatly appreciated. I have had this problem for some time, and I now have the latest Sawfish .debs (0.30.2). I am using Helix GNOME, and Debian woody. There are still some packages that are out-of-date, but I doubt they will fix the problem, since it has existed for quite a while now, and it seems specific to this machine, suggesting a configuration problem. Does anyone know of any configuration files that might cause this..? Regards, Alex. --- PGP/GPG Fingerprint: EFD1 AC6C 7ED5 E453 C367 AC7A B474 16E0 758D 7ED9 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/CM>CC/IT d- s:+ a16 C++()>$ UL>$ P---() L+++>+ E+>+ W+(-) N o? K? w--() !O M- !V PS+>+ PE- Y+ PGP t+ !5 X-- !R tv b DI D++ G>+++ e-- h! !r y --END GEEK CODE BLOCK--
Sawfish GNOME control center problem
Hi everyone, I seem to be having a problem with Sawfish's GNOME capplets: unlike all other capplets, Sawfish's capplets always require me to press "Try" before pressing "OK" to actually make the changes have any effect. Otherwise, they are silently ignored, as if I had pressed "Cancel". On all machines other than this one, the Sawfish capplets work in the expected manner; i.e., pressing "OK" makes the changes take effect. Any help in figuring out this problem out would be greatly appreciated. I have had this problem for some time, and I now have the latest Sawfish .debs (0.30.2). I am using Helix GNOME, and Debian woody. There are still some packages that are out-of-date, but I doubt they will fix the problem, since it has existed for quite a while now, and it seems specific to this machine, suggesting a configuration problem. Does anyone know of any configuration files that might cause this..? Regards, Alex. --- PGP/GPG Fingerprint: EFD1 AC6C 7ED5 E453 C367 AC7A B474 16E0 758D 7ED9 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/CM>CC/IT d- s:+ a16 C++()>$ UL>$ P---() L+++>+ E+>+ W+(-) N o? K? w--() !O M- !V PS+>+ PE- Y+ PGP t+ !5 X-- !R tv b DI D++ G>+++ e-- h! !r y --END GEEK CODE BLOCK-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
XFree86 4.0.1
Greetings, XFree86 4.0.1 is out now, as many of you are aware, I'm sure. I emailed Branden Robinson, the X maintainer, a week or two ago, and have yet to receive any responses or anything. Can anyone tell me what's going on with regards to packaging XFree86 4.0.1? Like, does Branden know about this, and have it on his agenda? I'd feel much more comfortable knowing that he's working on fixing up XFree86 3.3.6 for potato or something, than to be completely in the dark! Regards, Alex. --- PGP/GPG Fingerprint: EFD1 AC6C 7ED5 E453 C367 AC7A B474 16E0 758D 7ED9 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/CM>CC/IT d- s:+ a16 C++()>$ UL>$ P---() L+++>+ E+>+ W+(-) N o? K? w--() !O M- !V PS+>+ PE- Y+ PGP t+ !5 X-- !R tv b DI D++ G>+++ e-- h! !r y --END GEEK CODE BLOCK--
XFree86 4.0.1
Greetings, XFree86 4.0.1 is out now, as many of you are aware, I'm sure. I emailed Branden Robinson, the X maintainer, a week or two ago, and have yet to receive any responses or anything. Can anyone tell me what's going on with regards to packaging XFree86 4.0.1? Like, does Branden know about this, and have it on his agenda? I'd feel much more comfortable knowing that he's working on fixing up XFree86 3.3.6 for potato or something, than to be completely in the dark! Regards, Alex. --- PGP/GPG Fingerprint: EFD1 AC6C 7ED5 E453 C367 AC7A B474 16E0 758D 7ED9 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/CM>CC/IT d- s:+ a16 C++()>$ UL>$ P---() L+++>+ E+>+ W+(-) N o? K? w--() !O M- !V PS+>+ PE- Y+ PGP t+ !5 X-- !R tv b DI D++ G>+++ e-- h! !r y --END GEEK CODE BLOCK-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xfs-xtt stopped on upgrade, XF86_S3 at 50-70% CPU
Karl, What about restarting xfs-xtt and then the X server? Regards, Alex. --- PGP/GPG Fingerprint: EFD1 AC6C 7ED5 E453 C367 AC7A B474 16E0 758D 7ED9 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/CM>CC/IT d- s:+ a16 C++()>$ UL>$ P---() L+++>+ E+>+ W+(-) N o? K? w--() !O M- !V PS+>+ PE- Y+ PGP t+ !5 X-- !R tv b DI D++ G>+++ e-- h! !r y --END GEEK CODE BLOCK-- On 5 Jul 2000, Karl M. Hegbloom wrote: > >>>>> "Alexander" == Alexander Hvostov <[EMAIL PROTECTED]> writes: > > Alexander> xfs-xtt looks in /usr/X11R6/lib/X11/fonts/TrueType for its > *.ttf fonts (at > Alexander> least by default). > > Alexander> (1) Be sure you put your fonts there. > > Done. > > Alexander> (2) Be sure there is a file `fonts.dir' there. > > Done, created by `mkttfdir -e -o'. > > Alexander> (3) Since many *.ttf fonts have broken header information > (people are > Alexander> lazy, I guess), you might want to give mkttfdir these options > (which also > Alexander> gives oblique variants): -e -o > > Ok. > > Alexander> (4) Insure that xfs-xtt is referenced by your XF86Config file > (ordinarily > Alexander> in /etc/X11). To use UNIX domain sockets, a FontPath line > would look like: > > Alexander> FontPath "unix/:7100" > > Done, via `xset fp+ unix/:7100; xset fp rehash'. > > Alexander> (5) If all else fails (and you reach this step), try > reinstalling (dpkg > Alexander> --purge xfs-xtt) the package to restore its default (and > Alexander> sane) configuration. > > I tried that also, and have verified that the TrueType directory is > on the path in "/etc/X11/xfs/config". > > Neither `gfontsel' nor `xlsfonts' shows any of my truetype fonts in > the listing. What could be wrong? >
Re: xfs-xtt stopped on upgrade, XF86_S3 at 50-70% CPU
Karl, What about restarting xfs-xtt and then the X server? Regards, Alex. --- PGP/GPG Fingerprint: EFD1 AC6C 7ED5 E453 C367 AC7A B474 16E0 758D 7ED9 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/CM>CC/IT d- s:+ a16 C++()>$ UL>$ P---() L+++>+ E+>+ W+(-) N o? K? w--() !O M- !V PS+>+ PE- Y+ PGP t+ !5 X-- !R tv b DI D++ G>+++ e-- h! !r y --END GEEK CODE BLOCK-- On 5 Jul 2000, Karl M. Hegbloom wrote: > >>>>> "Alexander" == Alexander Hvostov <[EMAIL PROTECTED]> writes: > > Alexander> xfs-xtt looks in /usr/X11R6/lib/X11/fonts/TrueType for its *.ttf >fonts (at > Alexander> least by default). > > Alexander> (1) Be sure you put your fonts there. > > Done. > > Alexander> (2) Be sure there is a file `fonts.dir' there. > > Done, created by `mkttfdir -e -o'. > > Alexander> (3) Since many *.ttf fonts have broken header information (people are > Alexander> lazy, I guess), you might want to give mkttfdir these options (which >also > Alexander> gives oblique variants): -e -o > > Ok. > > Alexander> (4) Insure that xfs-xtt is referenced by your XF86Config file >(ordinarily > Alexander> in /etc/X11). To use UNIX domain sockets, a FontPath line would look >like: > > Alexander> FontPath "unix/:7100" > > Done, via `xset fp+ unix/:7100; xset fp rehash'. > > Alexander> (5) If all else fails (and you reach this step), try reinstalling >(dpkg > Alexander> --purge xfs-xtt) the package to restore its default (and > Alexander> sane) configuration. > > I tried that also, and have verified that the TrueType directory is > on the path in "/etc/X11/xfs/config". > > Neither `gfontsel' nor `xlsfonts' shows any of my truetype fonts in > the listing. What could be wrong? > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xfs-xtt stopped on upgrade, XF86_S3 at 50-70% CPU
Karl, xfs-xtt looks in /usr/X11R6/lib/X11/fonts/TrueType for its *.ttf fonts (at least by default). (1) Be sure you put your fonts there. (2) Be sure there is a file `fonts.dir' there. (3) Since many *.ttf fonts have broken header information (people are lazy, I guess), you might want to give mkttfdir these options (which also gives oblique variants): -e -o (4) Insure that xfs-xtt is referenced by your XF86Config file (ordinarily in /etc/X11). To use UNIX domain sockets, a FontPath line would look like: FontPath "unix/:7100" ...if you use port 7100/tcp for xfs-xtt; don't ask me why they did it this way. To use TCP/IP to reach the font server (for which you must enable listening in /etc/X11/xfs/config first), add a line something like this: FontPath "tcp/hostname:port" Hostname is, obviously, the hostname or IP address of the font server. The port is the port number (usually 7100) on which the font server is listening. (5) If all else fails (and you reach this step), try reinstalling (dpkg --purge xfs-xtt) the package to restore its default (and sane) configuration. Regards, Alex. --- PGP/GPG Fingerprint: EFD1 AC6C 7ED5 E453 C367 AC7A B474 16E0 758D 7ED9 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/CM>CC/IT d- s:+ a16 C++()>$ UL>$ P---() L+++>+ E+>+ W+(-) N o? K? w--() !O M- !V PS+>+ PE- Y+ PGP t+ !5 X-- !R tv b DI D++ G>+++ e-- h! !r y --END GEEK CODE BLOCK-- On 4 Jul 2000, Karl M. Hegbloom wrote: > > "Taketoshi" == Taketoshi Sano <[EMAIL PROTECTED]> writes: > > Taketoshi> Today, I happenly found the work-around for this problem. > > Taketoshi> Try the steps below after stopping/restarting the xfs-xtt: > > Taketoshi> 1) xset -fp > Taketoshi> (if you use unix socket, then "xset -fp 'unix/:7100'") > > Taketoshi> 2) xset fp default > > Taketoshi> It seems that Xserver can re-open the connection to the font > server > Taketoshi> using these steps on my system. > > Taketoshi> I don't know how we can use this information to fix the bugs, > Taketoshi> but I think this will help some users to work-around this > problem. > > I had `xfs-xtt' shut off for quite some time now, but yesterday, > started it up again to see if I could use some new ttf fonts I > downloaded from the TrueTeX site. > > I cannot get it working now, and do not know why. I finally located > `mkttfdir' and installed it, but that didn't make the ttf fonts show > up in `gfontsel'. > > What are the steps to getting truetype fonts installed, please? > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: xfs-xtt stopped on upgrade, XF86_S3 at 50-70% CPU
Karl, xfs-xtt looks in /usr/X11R6/lib/X11/fonts/TrueType for its *.ttf fonts (at least by default). (1) Be sure you put your fonts there. (2) Be sure there is a file `fonts.dir' there. (3) Since many *.ttf fonts have broken header information (people are lazy, I guess), you might want to give mkttfdir these options (which also gives oblique variants): -e -o (4) Insure that xfs-xtt is referenced by your XF86Config file (ordinarily in /etc/X11). To use UNIX domain sockets, a FontPath line would look like: FontPath "unix/:7100" ...if you use port 7100/tcp for xfs-xtt; don't ask me why they did it this way. To use TCP/IP to reach the font server (for which you must enable listening in /etc/X11/xfs/config first), add a line something like this: FontPath "tcp/hostname:port" Hostname is, obviously, the hostname or IP address of the font server. The port is the port number (usually 7100) on which the font server is listening. (5) If all else fails (and you reach this step), try reinstalling (dpkg --purge xfs-xtt) the package to restore its default (and sane) configuration. Regards, Alex. --- PGP/GPG Fingerprint: EFD1 AC6C 7ED5 E453 C367 AC7A B474 16E0 758D 7ED9 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/CM>CC/IT d- s:+ a16 C++()>$ UL>$ P---() L+++>+ E+>+ W+(-) N o? K? w--() !O M- !V PS+>+ PE- Y+ PGP t+ !5 X-- !R tv b DI D++ G>+++ e-- h! !r y --END GEEK CODE BLOCK-- On 4 Jul 2000, Karl M. Hegbloom wrote: > > "Taketoshi" == Taketoshi Sano <[EMAIL PROTECTED]> writes: > > Taketoshi> Today, I happenly found the work-around for this problem. > > Taketoshi> Try the steps below after stopping/restarting the xfs-xtt: > > Taketoshi> 1) xset -fp > Taketoshi> (if you use unix socket, then "xset -fp 'unix/:7100'") > > Taketoshi> 2) xset fp default > > Taketoshi> It seems that Xserver can re-open the connection to the font server > Taketoshi> using these steps on my system. > > Taketoshi> I don't know how we can use this information to fix the bugs, > Taketoshi> but I think this will help some users to work-around this problem. > > I had `xfs-xtt' shut off for quite some time now, but yesterday, > started it up again to see if I could use some new ttf fonts I > downloaded from the TrueTeX site. > > I cannot get it working now, and do not know why. I finally located > `mkttfdir' and installed it, but that didn't make the ttf fonts show > up in `gfontsel'. > > What are the steps to getting truetype fonts installed, please? > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
