Re: xfs 4.1: 75dpi vs 100dpi
Harald Dunkel wrote: How can I choose the default font size when using xfs? Even though I started X via '$X11/bin/xinit -- -quiet -dpi 75', I still get the giant 100dpi fonts, e.g. in Mozilla. If the font server serves 100dpi fonts, there's nothing the X server can do about that. Changing the catalogue sequence in /etc/X11/fs/config helps, but since xfs should be a network service suitable for several local and remote users, I doubt that this is the right way. AFAIK it's the only way. You could run several font servers for different resolutions or whatever. -- Earthling Michel Dänzer (MrCooper)\ Debian GNU/Linux (powerpc) developer CS student, Free Software enthusiast \XFree86 and DRI project member -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.1.0pre1v1.3 on Alpha
As it turns out, one can add an option in the Device Section of the XF86Config file: Option NoInt10 Good to know. I looked for something like that, but it's not mentioned in the user-side documentation at all. I tried this and it does work on my system, but for the record is spelled NoINT10. It would be much better if we could determine what it is about running int10 on some cards' BIOS code on an LX that causes problems. And unfortunately it's a tough nut to crack because it leaves the system in an unusable state. Unfortunately I think it's gonna take some serious code study by someone who's familiar with the minutia of the LX (or does it die on a Miata too?) So, bottom line WRT the patches, is that they provide the best safety against uninformed folks using 3DFx cards on LX-style machines, but I don't recommend those patches be passed along to XFree86. Yes, I agree, since we have the nice option that makes things work once again. And now that it's been discussed here, maybe affected people will actually find the appropriate option via a web search. Thanks Jay! -Doug -- Doug Larrick [EMAIL PROTECTED] [EMAIL PROTECTED] AIM: DougLarick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.1.0pre1v1.3 on Alpha
[EMAIL PROTECTED] wrote: As it turns out, one can add an option in the Device Section of the XF86Config file: Option NoInt10 We have to be careful with that option. Many video cards need to use IRQs in order to function. -- ** Derek J Witt** * Email: mailto:[EMAIL PROTECTED] * * Home Page: http://www.flinthills.com/~djw/ * *** Houston, the Eagle has landed and laid an egg! -- Unknown ** -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
xfree86-4.1.0-0pre1v2 test packages for hurd-i386 uploaded
Hi, I uploaded to http://people.debian.org/~brinkmd/xfree86-4.1.0-0pre1v2/ : BTW, it would be good if someone who has interests in the Hurd and X (and especially X on the Hurd) would join the X task force and test Brandens packags early and regularly. Branden has a repository for such packages (and if somebody wants to move the below packaegs into it, be my guest). Thanks, Marcus Date: Wed, 27 Jun 2001 09:59:46 + Source: xfree86 Binary: xserver-common xlibs-dev xfs xfree86-common xfonts-pex xlibmesa-dev xspecs xlibmesa3 xfonts-cyrillic xlibmesa3-dbg xserver-xfree86 xlibs-dbg libxaw6 libxaw7 xterm xvfb xfonts-scalable xfonts-75dpi xlib6g proxymngr libxaw6-dev libdps1-dbg xlib6g-dev xfonts-base xutils libxaw7-dev xnest xlibs libxaw6-dbg xmh lbxproxy libxaw7-dbg xfonts-base-transcoded xbase-clients xprt xlibosmesa3 xlibosmesa-dev twm xfwp xfonts-100dpi-transcoded xlibosmesa3-dbg xfonts-100dpi xdm libdps-dev xfonts-75dpi-transcoded libdps1 Architecture: hurd-i386 Version: 4.1.0-0pre1v2 Distribution: unstable Maintainer: Marcus Brinkmann [EMAIL PROTECTED] Changed-By: Branden Robinson [EMAIL PROTECTED] Files: 8943aba5bce32cdaf23fe174b9ab1247 105770 x11 optional lbxproxy_4.1.0-0pre1v2_hurd-i386.deb 05344f8cd0309ec30ec930339abb0052 142482 libs optional libdps1_4.1.0-0pre1v2_hurd-i386.deb 532bbd0b3c8f2c35c703be6e2a6694a2 386114 devel extra libdps1-dbg_4.1.0-0pre1v2_hurd-i386.deb f37c58b9fab5d107bf2320a2ecfc673f 207212 devel optional libdps-dev_4.1.0-0pre1v2_hurd-i386.deb f9f7a95f5a98f9367302a3f891bdb696 139546 libs optional libxaw6_4.1.0-0pre1v2_hurd-i386.deb 918a805ad6e864c1df1100f547e072bc 311726 devel extra libxaw6-dbg_4.1.0-0pre1v2_hurd-i386.deb 11e900817884367cca07bd3596d3014b 267240 devel optional libxaw6-dev_4.1.0-0pre1v2_hurd-i386.deb ae09e48e176aa3571a136b27874f9441 186514 libs optional libxaw7_4.1.0-0pre1v2_hurd-i386.deb 9dff3250417cad97ab61092826b1e8d0 412136 devel extra libxaw7-dbg_4.1.0-0pre1v2_hurd-i386.deb f4468559bcd70c241da1280a6ff1071a 267118 devel optional libxaw7-dev_4.1.0-0pre1v2_hurd-i386.deb 15f5546f38554d2043e03b807cdd0a9f 48602 x11 optional proxymngr_4.1.0-0pre1v2_hurd-i386.deb b97c2d3bf95ccff6067b8881b920553d 124524 x11 optional twm_4.1.0-0pre1v2_hurd-i386.deb 10742eb0ac047ab7fb20fd768f4bda0d 1426854 x11 optional xbase-clients_4.1.0-0pre1v2_hurd-i386.deb d29d8585249ce7e6eb0f11fc437e13d4 135936 x11 optional xdm_4.1.0-0pre1v2_hurd-i386.deb f93209847718d5d1c6c6fc1a4dcb1f2c 252814 x11 optional xfs_4.1.0-0pre1v2_hurd-i386.deb 634ee9a3a6a52c0a25d4e411143b95dc 54294 x11 optional xfwp_4.1.0-0pre1v2_hurd-i386.deb e384c3b4b54fd5d3ac12e2f2996a2137 321126 libs optional xlibmesa3_4.1.0-0pre1v2_hurd-i386.deb 47298a2f11582b268210d60412bc631f 33860 devel extra xlibmesa3-dbg_4.1.0-0pre1v2_hurd-i386.deb 42e11ff713283292d36e90fc65a8d61c 508622 devel optional xlibmesa-dev_4.1.0-0pre1v2_hurd-i386.deb 042bf4f4f00cfbd874a9e23385eb0809 1181226 libs optional xlibs_4.1.0-0pre1v2_hurd-i386.deb c8371c31bf8fa63f825445921f161c3a 2476134 devel extra xlibs-dbg_4.1.0-0pre1v2_hurd-i386.deb c87fe807b4f03f95d5489b97ef890714 2922452 devel optional xlibs-dev_4.1.0-0pre1v2_hurd-i386.deb cc4e0e7921a495cbd38a3fda54f30dd2 97904 mail extra xmh_4.1.0-0pre1v2_hurd-i386.deb 8a3f4e72b88b982189672d4c839eedfe 1368072 x11 optional xnest_4.1.0-0pre1v2_hurd-i386.deb 56d75fbe45ccd3e7eba0b95c0e444923 1097762 x11 optional xprt_4.1.0-0pre1v2_hurd-i386.deb 841debec403975379ca00102a1df5bc6 178416 x11 optional xserver-common_4.1.0-0pre1v2_hurd-i386.deb ce41eeff4619b41614dcb2b0aacadbcf 4133236 x11 optional xserver-xfree86_4.1.0-0pre1v2_hurd-i386.deb f2f160c364b3ec2bcf6e76ab9e7d5c18 326576 x11 optional xterm_4.1.0-0pre1v2_hurd-i386.deb 6f3ab7bfd96afb76a9843a05b987aef4 377688 x11 optional xutils_4.1.0-0pre1v2_hurd-i386.deb 949098d58f98c4f0be81a1e5daa26f3d 1468468 x11 optional xvfb_4.1.0-0pre1v2_hurd-i386.deb -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.1.0pre1v1.3 on Alpha
On Sat, Jun 30, 2001 at 12:36:14PM -0400, [EMAIL PROTECTED] wrote: As it turns out, one can add an option in the Device Section of the XF86Config file: Option NoInt10 Good to know. I looked for something like that, but it's not mentioned in the user-side documentation at all. I tried this and it does work on my system, but for the record is spelled NoINT10. Hmm; actually, I think it may do the comparison case-less, as I have had it work as NoInt10 and noint10... And unfortunately it's a tough nut to crack because it leaves the system in an unusable state. Unfortunately I think it's gonna take some serious code study by someone who's familiar with the minutia of the LX (or does it die on a Miata too?) I think it does crash on MIATA as well, but I'm not certain. And yes, it's tough. It may not even be the fault of the int10 code, either. Last one we had to go to this level with, was a problem we saw on *all* boxes with Radeon 32MB SDR PCI. It turned out to be a problem caused by running the BIOS more than once - it would work the first time (ie when the SRM console's BIOS emulator ran on the cold card), but then when int10 was run later under XFree86, it would make a mistake because the state of the card was already set up. I'd call that a problem in the BIOS code myself, but there's rather small chance of getting it fixed... ;-} Yes, I agree, since we have the nice option that makes things work once again. And now that it's been discussed here, maybe affected people will actually find the appropriate option via a web search. Well, an entry in release notes is always in order, or a FAQ if there's an appropriate one. I posted that workaround, as well as some others, to axp-list, and it seemed to help... ;-} --Jay++ - Jay A EstabrookAlpha Engineering - LINUX Project Compaq Computer Corp. - MRO1-2/K20 (508) 467-2080 200 Forest Street, Marlboro MA 01752 [EMAIL PROTECTED] - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.1.0pre1v1.3 on Alpha
Jay Estabrook wrote: As it turns out, one can add an option in the Device Section of the XF86Config file: Option NoInt10 to prevent int10 from getting run on a 3DFx card. Unfortunately, this does not work for some other drivers, so is not a general solution to int10-related problems. AFAIK this option is handled by the int10 module itself so it should work with any driver. Otherwise, there's probably another problem. -- Earthling Michel Dänzer (MrCooper)\ Debian GNU/Linux (powerpc) developer CS student, Free Software enthusiast \XFree86 and DRI project member -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.1.0pre1v1.3 on Alpha
On Sat, Jun 30, 2001 at 04:42:34PM -0400, Jay Estabrook wrote: Well, an entry in release notes is always in order, or a FAQ if there's an appropriate one. I posted that workaround, as well as some others, to axp-list, and it seemed to help... ;-} Jay, I just wanted to let you know that you can always feel free to contact me directly when it comes to any Debian XFree86 support issues for Alpha. I am pretty upset about Compaq selling this architecture to the worst possible buyer, and I'd like to do what I can to ensure that people don't migrate away from the Alpha because XFree86 doesn't work on their Debian systems. I'd say more, but references to appeasement and the Sudetenland would probably invoke Godwin's Law... Thanks for your all your efforts, past and future. -- G. Branden Robinson| Software engineering: that part of Debian GNU/Linux | computer science which is too difficult [EMAIL PROTECTED] | for the computer scientist. http://people.debian.org/~branden/ | PGP signature
XFree 4.0.3 and 4.1 on s390
Hi, I am currently working on XFree 4.0.3 and 4.1 for s390. Below are some issues I have found so far. First of all, glide shouldn't be prerequisite for XFree on s390. The xkb files are still in /usr/X11R6/lib/X11/xkb instead of /etc/X11/xkb. I am not quite sure what the reason is, but suspect that it is caused by the missing Xserver part of the configuration. I have fixed it temporarily by the following patch. --- rules Mon Jun 25 21:01:18 2001 +++ rules.s390 Mon Jun 25 14:16:16 2001 @@ -138,6 +138,11 @@ build-tree/xc/programs/Xserver/hw/xfree86/doc/README.fonts \ build-tree/xc/programs/Xserver/hw/xfree86/doc/RELNOTES \ debian/tmp/usr/X11R6/lib/X11/doc + mkdir -p $(DEBTREEDIR)/etc/X11/xkb + rm $(DEBTREEDIR)/usr/X11R6/lib/X11/xkb/compiled + mv $(DEBTREEDIR)/usr/X11R6/lib/X11/xkb/* $(DEBTREEDIR)/etc/X11/xkb + ln -sf ../../../../../etc/X11/xkb/* $(DEBTREEDIR)/usr/X11R6/lib/X11/xkb/ + ln -sf ../../../../../var/lib/xkb $(DEBTREEDIR)/usr/X11R6/lib/X11/xkb/compiled else # remove the upstream symlink X - XFree86 rm $(DEBTREEDIR)/usr/X11R6/bin/X The following links are broken. I don't know if it's s390 specific. grep: ./libdps-dev/usr/X11R6/lib/libpsres.so: No such file or directory grep: ./libdps-dev/usr/X11R6/lib/libdpstk.so: No such file or directory grep: ./libdps-dev/usr/X11R6/lib/libdps.so: No such file or directory grep: ./libxaw6-dev/usr/X11R6/lib/libXaw.so: No such file or directory grep: ./libxaw7-dev/usr/X11R6/lib/libXaw.so: No such file or directory grep: ./xbase-clients/usr/X11R6/lib/X11/xinit: No such file or directory grep: ./xbase-clients/usr/share/man/man1/xkbbell.1x.gz: No such file or directory grep: ./xbase-clients/usr/share/man/man1/xkbvleds.1x.gz: No such file or directory grep: ./xbase-clients/usr/share/man/man1/xkbwatch.1x.gz: No such file or directory grep: ./xlibmesa-dev/usr/lib/libGLU.so: No such file or directory grep: ./xlibmesa-dev/usr/lib/libGL.so: No such file or directory grep: ./xlibs-dev/usr/X11R6/lib/libxrx.so: No such file or directory grep: ./xlibs-dev/usr/X11R6/lib/libXtst.so: No such file or directory grep: ./xlibs-dev/usr/X11R6/lib/libXt.so: No such file or directory grep: ./xlibs-dev/usr/X11R6/lib/libXrender.so: No such file or directory grep: ./xlibs-dev/usr/X11R6/lib/libXpm.so: No such file or directory grep: ./xlibs-dev/usr/X11R6/lib/libXp.so: No such file or directory grep: ./xlibs-dev/usr/X11R6/lib/libXmu.so: No such file or directory grep: ./xlibs-dev/usr/X11R6/lib/libXi.so: No such file or directory grep: ./xlibs-dev/usr/X11R6/lib/libXft.so: No such file or directory grep: ./xlibs-dev/usr/X11R6/lib/libXext.so: No such file or directory grep: ./xlibs-dev/usr/X11R6/lib/libXIE.so: No such file or directory grep: ./xlibs-dev/usr/X11R6/lib/libX11.so: No such file or directory grep: ./xlibs-dev/usr/X11R6/lib/libSM.so: No such file or directory grep: ./xlibs-dev/usr/X11R6/lib/libPEX5.so: No such file or directory grep: ./xlibs-dev/usr/X11R6/lib/libICE.so: No such file or directory grep: ./xutils/usr/share/man/man1/bdftruncate.pl.1x.gz: No such file or directory grep: ./xutils/usr/share/man/man1/gccmakedep.1x.gz: No such file or directory grep: ./xutils/usr/share/man/man1/mergelib.1x.gz: No such file or directory grep: ./xutils/usr/share/man/man1/mkhtmlindex.1x.gz: No such file or directory grep: ./xutils/usr/share/man/man1/ucs2any.pl.1x.gz: No such file or directory grep: ./libxaw6-dbg/usr/X11R6/lib/debug/libXaw.so.6: No such file or directory grep: ./libxaw7-dbg/usr/X11R6/lib/debug/libXaw.so.7: No such file or directory I have sent the MANIFEST files for 4.0.3 and 4.1 directly to Branden. After I had created or changed xterm.docs.s390, xutils.files.s390, xlibs.files.s390 and xbase-clients.files.s390, the packages were built fine. I haven't tested them yet. Regards, Gerhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
PCI Radeon and X 4.1
Hey, I know the Radeon doesnt work with 3d yet, but is anyone using it for 2D? If so what version of X? what driver? and can I get a copy of your config? Ive had my PCI Radeon working for 2d in the past with X 4.0 and for a while it worked with X 4.1. In 4.0 I had to install the DRI stuff in addition to X and then use the driver named radeon. In X 4.1 there didnt seem to be a specific radeon driver, so I used the ati driver which worked for a while. Im not really sure what I changed on my system, I think it may have been the upgrade from pre 1.2 to 1.3 but who knows, now if i start X using the ATI driver it hangs my machine hard. By hard I mean ssh/telnet dont repsond, keyboard doesnt work, mouse doesnt work and if it werent for the sysrq key Id spend 30 minutes or so fscking giant hard drive. Thanks a ton in advance, Ilan [EMAIL PROTECTED]
Re: xfs 4.1: 75dpi vs 100dpi
Harald Dunkel wrote: How can I choose the default font size when using xfs? Even though I started X via '$X11/bin/xinit -- -quiet -dpi 75', I still get the giant 100dpi fonts, e.g. in Mozilla. If the font server serves 100dpi fonts, there's nothing the X server can do about that. Changing the catalogue sequence in /etc/X11/fs/config helps, but since xfs should be a network service suitable for several local and remote users, I doubt that this is the right way. AFAIK it's the only way. You could run several font servers for different resolutions or whatever. -- Earthling Michel Dänzer (MrCooper)\ Debian GNU/Linux (powerpc) developer CS student, Free Software enthusiast \XFree86 and DRI project member
Numeric keypad on thinkpad a21m
Does anyone know how to enable the numeric keypad on a thinkpad? Under windows the shift+numlk combo is used to toggle the numeric keypad on and off. However, under X 4.0.3 this doesn't work, it merely makes the relevant keys unusable. Any help would be much appreciated. Cheers Dave
XFree86 4.1.0pre1v1.3 on Alpha
First, let me say that I'm not a Debian developer, just an Alpha user who
wanted to upgrade to a more modern graphics card on his system, ran into
some trouble, and tracked it down.
The attached patch makes a PCI Voodoo3 3000 PCI card work on my Alpha
PC164LX. Without it, the system goes into a whole lot of bad during X
initialization: 'sync' works afterwards, but 'halt' does not.
The root of the problem is that the int10 subsystem is extremely broken for
Alpha, at least for the type of Alpha that I have (LX). After int10 has
done its work, calls to sleep(), usleep(), nanosleep(), etc. never return.
My patch simply disables the use of int10 (and therefore also DDC) in the
tdfx driver, like is done on PowerPC. This change probably precludes use
of a 3dfx card as a second head on Alpha. The functionality obviously
worked for someone, or it would not have been put in. But IMHO this way is
safer for more users.
BTW, 4.1.0pre1v1.3 works like a champ out-of-box on a Matrox Millennium II
in the same system.
I have to say, the Debian packagaing makes it *much* easier (albeit
time-consuming) for an outsider to approach building the monster that is
XFree86. Thanks for listening.
-Doug
--
Doug Larrick [EMAIL PROTECTED] [EMAIL PROTECTED] AIM: DougLarick--- xc/programs/Xserver/hw/xfree86/drivers/tdfx/tdfx_driver.c.orig Sat Jun
30 09:32:46 2001
+++ xc/programs/Xserver/hw/xfree86/drivers/tdfx/tdfx_driver.c Sat Jun 30
09:34:00 2001
@@ -668,7 +668,7 @@
pTDFX-pEnt = xf86GetEntityInfo(pScrn-entityList[0]);
if (flags PROBE_DETECT) {
-#if !defined(__powerpc__)
+#if !defined(__powerpc__) !defined(__alpha__)
TDFXProbeDDC(pScrn, pTDFX-pEnt-index);
return TRUE;
#else
@@ -685,7 +685,7 @@
/* Allocate a vgaHWRec */
if (!vgaHWGetHWRec(pScrn)) return FALSE;
-#if !defined(__powerpc__)
+#if !defined(__powerpc__) !defined(__alpha__)
if (xf86LoadSubModule(pScrn, int10)) {
xf86Int10InfoPtr pInt;
xf86DrvMsg(pScrn-scrnIndex, X_INFO,
@@ -1006,7 +1006,7 @@
xf86LoaderReqSymLists(ramdacSymbols, NULL);
}
-#if !defined(__powerpc__)
+#if !defined(__powerpc__) !defined(__alpha__)
/* Load DDC if needed */
/* This gives us DDC1 - we should be able to get DDC2B using i2c */
if (!xf86LoadSubModule(pScrn, ddc)) {
Re: XFree86 4.1.0pre1v1.3 on Alpha
On Sat, Jun 30, 2001 at 10:06:05AM -0400, Doug Larrick wrote: The attached patch makes a PCI Voodoo3 3000 PCI card work on my Alpha PC164LX. Without it, the system goes into a whole lot of bad during X initialization: 'sync' works afterwards, but 'halt' does not. The root of the problem is that the int10 subsystem is extremely broken for Alpha, at least for the type of Alpha that I have (LX). After int10 has done its work, calls to sleep(), usleep(), nanosleep(), etc. never return. My patch simply disables the use of int10 (and therefore also DDC) in the tdfx driver, like is done on PowerPC. This change probably precludes use of a 3dfx card as a second head on Alpha. The functionality obviously worked for someone, or it would not have been put in. But IMHO this way is safer for more users. I had a similar problem with a Voodoo Banshee card in an LX, though it was more serious - it crashed the machine back to SRM console. But that same card, and a Voodoo3 3000, work just fine in the newer (EV6) boxes, without the need for disabling int10 processing. The same type of int10-related problem has cropped up with other drivers on other cards when run on an LX; I seem to remember it was the GLINT driver, but it could have been the R128 one. As it turns out, one can add an option in the Device Section of the XF86Config file: Option NoInt10 to prevent int10 from getting run on a 3DFx card. Unfortunately, this does not work for some other drivers, so is not a general solution to int10-related problems. It would be much better if we could determine what it is about running int10 on some cards' BIOS code on an LX that causes problems. It's been on my TODO list for a while, and Egbert Eich, one of the XFree86 fellows responsible for int10 and who has a number of Alphas, would also like to see a solution. But to this point, the time hasn't been available to attack it. I have some int10-related patches against 4.1.0 that remove most if not all of the unaligned accesses that occur during the running of int10, but I don't believe they solve this problem with Voodoo cards. So, bottom line WRT the patches, is that they provide the best safety against uninformed folks using 3DFx cards on LX-style machines, but I don't recommend those patches be passed along to XFree86. They are overkill, don't apply to all Alpha machines, and will have side-effects when attempting to do multi-head with 3DFx cards, as Doug noted. --Jay++ - Jay A EstabrookAlpha Engineering - LINUX Project Compaq Computer Corp. - MRO1-2/K20 (508) 467-2080 200 Forest Street, Marlboro MA 01752 [EMAIL PROTECTED] -
Re: XFree86 4.1.0pre1v1.3 on Alpha
As it turns out, one can add an option in the Device Section of the XF86Config file: Option NoInt10 Good to know. I looked for something like that, but it's not mentioned in the user-side documentation at all. I tried this and it does work on my system, but for the record is spelled NoINT10. It would be much better if we could determine what it is about running int10 on some cards' BIOS code on an LX that causes problems. And unfortunately it's a tough nut to crack because it leaves the system in an unusable state. Unfortunately I think it's gonna take some serious code study by someone who's familiar with the minutia of the LX (or does it die on a Miata too?) So, bottom line WRT the patches, is that they provide the best safety against uninformed folks using 3DFx cards on LX-style machines, but I don't recommend those patches be passed along to XFree86. Yes, I agree, since we have the nice option that makes things work once again. And now that it's been discussed here, maybe affected people will actually find the appropriate option via a web search. Thanks Jay! -Doug -- Doug Larrick [EMAIL PROTECTED] [EMAIL PROTECTED] AIM: DougLarick
Re: XFree86 4.1.0pre1v1.3 on Alpha
[EMAIL PROTECTED] wrote: As it turns out, one can add an option in the Device Section of the XF86Config file: Option NoInt10 We have to be careful with that option. Many video cards need to use IRQs in order to function. -- ** Derek J Witt** * Email: mailto:[EMAIL PROTECTED] * * Home Page: http://www.flinthills.com/~djw/ * *** Houston, the Eagle has landed and laid an egg! -- Unknown **
hurd-i386 support changes
Hi, I tested and uploaded xfree86-4.1.0-0pre1v2, and it was quite smooth. The following patch is requried. A new MANIFEST.hurd-i386 file is attached (I lost the original one, so no patch for that, sorry). Thanks, Marcus diff -ruN debian.prior/patches/800_gnu_config.diff debian/patches/800_gnu_config.diff --- debian.prior/patches/800_gnu_config.diffSat Jun 30 21:18:55 2001 +++ debian/patches/800_gnu_config.diff Sat Jun 30 21:20:02 2001 @@ -14,7 +14,6 @@ +#define HasPamYES +#define PamLibraries -lpam -rdynamic -ldl +#define XFree86Devel YES -+#define Freetype2Dir /usr +#define SystemManDirectory/usr/share/man +#define HasTk YES +#define TkLibDir /usr/lib @@ -36,6 +35,7 @@ +#define SpecsDocDirs BDF CTEXT FSProtocol GL ICCCM ICE PM Render SM X11 XDMCP XIM XLFD XProtocol Xaw Xext Xi Xmu Xserver Xt Xv i18n rstart xfs xterm xtrans +/* we build-depend on libfreetype6-dev (FreeType 2.x) */ +#define BuildFreetype2Library NO ++#define HasFreetype2 YES +#define Freetype2Dir /usr +#define XAppLoadDir EtcX11Directory/app-defaults +#define XFileSearchPathDefault Concat4(EtcX11Directory/%L/%T/%N%C,%S:EtcX11Directory/%l/%T/%N%C,%S:EtcX11Directory/%T/%N%C,%S:EtcX11Directory/%L/%T/%N%S:EtcX11Directory/%l/%T/%N%S:EtcX11Directory/%T/%N%S):Concat4($(LIBDIR)/%L/%T/%N%C,%S:$(LIBDIR)/%l/%T/%N%C,%S:$(LIBDIR)/%T/%N%C,%S:$(LIBDIR)/%L/%T/%N%S:$(LIBDIR)/%l/%T/%N%S:$(LIBDIR)/%T/%N%S) diff -ruN debian.prior/xlibmesa3.files.hurd-i386 debian/xlibmesa3.files.hurd-i386 --- debian.prior/xlibmesa3.files.hurd-i386 Thu Jan 1 01:00:00 1970 +++ debian/xlibmesa3.files.hurd-i386Sat Jun 30 21:21:24 2001 @@ -0,0 +1,2 @@ +usr/X11R6/lib/libGL.so.1.2 +usr/X11R6/lib/libGLU.so.1.3 -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de MANIFEST.hurd-i386.gz Description: Binary data
Re: hurd-i386 support changes
On Sat, Jun 30, 2001 at 09:23:50PM +0200, Marcus Brinkmann wrote: I tested and uploaded xfree86-4.1.0-0pre1v2, and it was quite smooth. The following patch is requried. A new MANIFEST.hurd-i386 file is attached (I lost the original one, so no patch for that, sorry). Thanks a lot, Marcus! -- G. Branden Robinson| Men use thought only to justify their Debian GNU/Linux | wrong doings, and speech only to conceal [EMAIL PROTECTED] | their thoughts. http://people.debian.org/~branden/ | -- Voltaire pgpVmMn3NduvT.pgp Description: PGP signature
Re: XFree86 4.1.0pre1v1.3 on Alpha
On Sat, Jun 30, 2001 at 12:36:14PM -0400, [EMAIL PROTECTED] wrote: As it turns out, one can add an option in the Device Section of the XF86Config file: Option NoInt10 Good to know. I looked for something like that, but it's not mentioned in the user-side documentation at all. I tried this and it does work on my system, but for the record is spelled NoINT10. Hmm; actually, I think it may do the comparison case-less, as I have had it work as NoInt10 and noint10... And unfortunately it's a tough nut to crack because it leaves the system in an unusable state. Unfortunately I think it's gonna take some serious code study by someone who's familiar with the minutia of the LX (or does it die on a Miata too?) I think it does crash on MIATA as well, but I'm not certain. And yes, it's tough. It may not even be the fault of the int10 code, either. Last one we had to go to this level with, was a problem we saw on *all* boxes with Radeon 32MB SDR PCI. It turned out to be a problem caused by running the BIOS more than once - it would work the first time (ie when the SRM console's BIOS emulator ran on the cold card), but then when int10 was run later under XFree86, it would make a mistake because the state of the card was already set up. I'd call that a problem in the BIOS code myself, but there's rather small chance of getting it fixed... ;-} Yes, I agree, since we have the nice option that makes things work once again. And now that it's been discussed here, maybe affected people will actually find the appropriate option via a web search. Well, an entry in release notes is always in order, or a FAQ if there's an appropriate one. I posted that workaround, as well as some others, to axp-list, and it seemed to help... ;-} --Jay++ - Jay A EstabrookAlpha Engineering - LINUX Project Compaq Computer Corp. - MRO1-2/K20 (508) 467-2080 200 Forest Street, Marlboro MA 01752 [EMAIL PROTECTED] -
Re: XFree86 4.1.0pre1v1.3 on Alpha
Jay Estabrook wrote: As it turns out, one can add an option in the Device Section of the XF86Config file: Option NoInt10 to prevent int10 from getting run on a 3DFx card. Unfortunately, this does not work for some other drivers, so is not a general solution to int10-related problems. AFAIK this option is handled by the int10 module itself so it should work with any driver. Otherwise, there's probably another problem. -- Earthling Michel Dänzer (MrCooper)\ Debian GNU/Linux (powerpc) developer CS student, Free Software enthusiast \XFree86 and DRI project member
Re: XFree86 4.1.0-0pre1v2 available for i386,powerpc,sparc
Chris Cheney wrote: I noticed that if you select /dev/gpmdata as your mouse device it still includes the detected mouse device (eg /dev/input/mice) this causes a problem usually if you are using gpm since gpm and X fight for the main device. Not for /dev/input/mice, it can be opened and read by any number of processes without problems. In fact, you don't need the GPM repeater with it in the first place. Also it might be good to set the device type of gpmdata to ImPS/2 instead of Intellimouse since that is the type that is emulated by /dev/input/mice. The protocol emitted by the GPM repeater depends on GPM configuration only. -- Earthling Michel Dänzer (MrCooper)\ Debian GNU/Linux (powerpc) developer CS student, Free Software enthusiast \XFree86 and DRI project member
Re: XFree86 4.1.0pre1v1.3 on Alpha
On Sat, Jun 30, 2001 at 04:42:34PM -0400, Jay Estabrook wrote: Well, an entry in release notes is always in order, or a FAQ if there's an appropriate one. I posted that workaround, as well as some others, to axp-list, and it seemed to help... ;-} Jay, I just wanted to let you know that you can always feel free to contact me directly when it comes to any Debian XFree86 support issues for Alpha. I am pretty upset about Compaq selling this architecture to the worst possible buyer, and I'd like to do what I can to ensure that people don't migrate away from the Alpha because XFree86 doesn't work on their Debian systems. I'd say more, but references to appeasement and the Sudetenland would probably invoke Godwin's Law... Thanks for your all your efforts, past and future. -- G. Branden Robinson| Software engineering: that part of Debian GNU/Linux | computer science which is too difficult [EMAIL PROTECTED] | for the computer scientist. http://people.debian.org/~branden/ | pgpigpfJu4Cju.pgp Description: PGP signature
