Re: strange looking fonts.
Seth Arnold <[EMAIL PROTECTED]> writes: > Russell, the debian-x mail list (in recent times anyway) is more > intended for developers and ginuea pigs of XF86 4.0. debian-users is > more appropriate. > > What I would imagine to fix your problem is to edit your > /etc/X11/XF86Config file. I bet the 100dpi fonts are listed before the > 75 dpi fonts. If so, swap their order and restart X. You could also just purge the xfonts-100dpi package ;-) > If this doesn't fix it, then perhaps mucking with the X server's idea of > the DPI of the display is the only way to go. -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
[Michael@Meding.net: You XF4.01 Phase2 packages]
Someone want to mail him my mini-FAQ, or invite him to subscribe? - Forwarded message from Michael Meding <[EMAIL PROTECTED]> - From: Michael Meding <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: You XF4.01 Phase2 packages Date: Tue, 10 Oct 2000 01:55:48 + Delivered-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Message-ID: <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i686) X-Accept-Language: de-DE, de, en X-Loop-Detect: 1 Hi Branden, I have downloaded the packages you have packed via dselect (for somebody who just fiddles around with debian and normally uses redhat packages the deb tools a really different to use. Especially the sources.list file). XF4.01 fired up nicely and without a glitch. Should the sources build on my system cleanly (system is potato with nothing else despite XF4.01 and helixcode packages) ? Anyway, I just wanted to thank you for the good work (upgrade was kind of pain free compared to the rpm system). What are the issues that needs to be fixed with 4.01 ? Greetings Michael - End forwarded message - -- G. Branden Robinson| The basic test of freedom is perhaps Debian GNU/Linux | less in what we are free to do than in [EMAIL PROTECTED] | what we are free not to do. http://deadbeast.net/~branden/ | -- Eric Hoffer pgpRnIpPhlD3Y.pgp Description: PGP signature
Re: [aaron@eazel.com: xfontsel]
* Branden Robinson in "[EMAIL PROTECTED]: xfontsel]" dated 2000/10/09 * 20:31 wrote: > - Forwarded message from Aaron Brick <[EMAIL PROTECTED]> - > > From: Aaron Brick <[EMAIL PROTECTED]> > Subject: xfontsel > Date: Mon, 09 Oct 2000 12:11:35 -0700 > > sorry to bug you. xfontsel dies on me mysteriously when i click on > anything in its window, saying "Error: XtMakeGeometryRequest - parent > not composite." i would be trying to solve the problem if i had any > clue what that error meant, but i don't, and so i hope you can > provide a little insight. the system is halfway to woody - X is > 4.0.1-0phase2v13. I was going to mention the same problem in ghostview and gv as well, it seems to be something in the Xt library based on the function name but I haven't had time to do a backtrace, maybe I'll try that now... doesn't seem to dump core, guess I'll either have to look at the source or hope someone has already fixed it. -- shaky recall pgptNiVButoly.pgp Description: PGP signature
[aaron@eazel.com: xfontsel]
- Forwarded message from Aaron Brick <[EMAIL PROTECTED]> - From: Aaron Brick <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: xfontsel Date: Mon, 09 Oct 2000 12:11:35 -0700 Delivered-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Message-ID: <[EMAIL PROTECTED]> Organization: Eazel, Inc. X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en hi branden, sorry to bug you. xfontsel dies on me mysteriously when i click on anything in its window, saying "Error: XtMakeGeometryRequest - parent not composite." i would be trying to solve the problem if i had any clue what that error meant, but i don't, and so i hope you can provide a little insight. the system is halfway to woody - X is 4.0.1-0phase2v13. again, sorry for bothering you. thanks for your time. aaron. __ / |aaron brick | |[EMAIL PROTECTED] |650 940 2080 | |research & test engineer |eazel, inc. \___ - End forwarded message - -- G. Branden Robinson|I must despise the world which does not Debian GNU/Linux |know that music is a higher revelation [EMAIL PROTECTED] |than all wisdom and philosophy. http://deadbeast.net/~branden/ |-- Ludwig van Beethoven pgpd7Fcp6Ec1H.pgp Description: PGP signature
[Michael@Meding.net: You XF4.01 Phase2 packages]
Someone want to mail him my mini-FAQ, or invite him to subscribe? - Forwarded message from Michael Meding <[EMAIL PROTECTED]> - From: Michael Meding <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: You XF4.01 Phase2 packages Date: Tue, 10 Oct 2000 01:55:48 + Delivered-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Message-ID: <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i686) X-Accept-Language: de-DE, de, en X-Loop-Detect: 1 Hi Branden, I have downloaded the packages you have packed via dselect (for somebody who just fiddles around with debian and normally uses redhat packages the deb tools a really different to use. Especially the sources.list file). XF4.01 fired up nicely and without a glitch. Should the sources build on my system cleanly (system is potato with nothing else despite XF4.01 and helixcode packages) ? Anyway, I just wanted to thank you for the good work (upgrade was kind of pain free compared to the rpm system). What are the issues that needs to be fixed with 4.01 ? Greetings Michael - End forwarded message - -- G. Branden Robinson| The basic test of freedom is perhaps Debian GNU/Linux | less in what we are free to do than in [EMAIL PROTECTED] | what we are free not to do. http://deadbeast.net/~branden/ | -- Eric Hoffer PGP signature
Re: [aaron@eazel.com: xfontsel]
* Branden Robinson in "[[EMAIL PROTECTED]: xfontsel]" dated 2000/10/09 * 20:31 wrote: > - Forwarded message from Aaron Brick <[EMAIL PROTECTED]> - > > From: Aaron Brick <[EMAIL PROTECTED]> > Subject: xfontsel > Date: Mon, 09 Oct 2000 12:11:35 -0700 > > sorry to bug you. xfontsel dies on me mysteriously when i click on > anything in its window, saying "Error: XtMakeGeometryRequest - parent > not composite." i would be trying to solve the problem if i had any > clue what that error meant, but i don't, and so i hope you can > provide a little insight. the system is halfway to woody - X is > 4.0.1-0phase2v13. I was going to mention the same problem in ghostview and gv as well, it seems to be something in the Xt library based on the function name but I haven't had time to do a backtrace, maybe I'll try that now... doesn't seem to dump core, guess I'll either have to look at the source or hope someone has already fixed it. -- shaky recall PGP signature
[aaron@eazel.com: xfontsel]
- Forwarded message from Aaron Brick <[EMAIL PROTECTED]> - From: Aaron Brick <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: xfontsel Date: Mon, 09 Oct 2000 12:11:35 -0700 Delivered-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Message-ID: <[EMAIL PROTECTED]> Organization: Eazel, Inc. X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en hi branden, sorry to bug you. xfontsel dies on me mysteriously when i click on anything in its window, saying "Error: XtMakeGeometryRequest - parent not composite." i would be trying to solve the problem if i had any clue what that error meant, but i don't, and so i hope you can provide a little insight. the system is halfway to woody - X is 4.0.1-0phase2v13. again, sorry for bothering you. thanks for your time. aaron. __ / |aaron brick | |[EMAIL PROTECTED] |650 940 2080 | |research & test engineer |eazel, inc. \___ - End forwarded message - -- G. Branden Robinson|I must despise the world which does not Debian GNU/Linux |know that music is a higher revelation [EMAIL PROTECTED] |than all wisdom and philosophy. http://deadbeast.net/~branden/ |-- Ludwig van Beethoven PGP signature
[PATCH] fbdev fixes
Geert Uytterhoeven has helped me get some things right in the X 4.x fbdev code
finally:
depth and bpp are now passed correctly in both directions, the former encoded
in the r,g,b lengths.
Given a PCI ID, fbdev_open_pci now scans all the framebuffer devices'
framebuffer and MMIO regions to find the one which matches the PCI device. A
similar approach might be used to find and claim the PCI device for a given
framebuffer device, thus removing the need to explicitly specify the PCI ID
when using fbdev. As I don't fully understand the X PCI code though, review
and comments are greatly appreciated here.
The framebuffer and MMIO mapping should now also work correctly for strange
hardware with unaligned regions, fixing problems with the display being off
horizontally and the like.
The infamous 'FIXME: might be wrong' comment about the pScrn->displayWidth =
pScrn->virtualX; has also proved right; displayWidth can be any number of
bytes for a framebuffer device, but only a pixel aligned value for X, which
let me only fix it correctly when using ShadowFB. But it should work in most
cases even without. At least better than before ;)
Last but not least, the parameter for the FBIOBLANK ioctl had the wrong type,
but nobody noticed that I guess.
This has been successfully tested by me and a couple of other people. Feedback
always appreciated.
Michel
--
Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \ member of XFree86 and The DRI ProjectIndex: fbdevhw/fbdevhw.c
===
RCS file: /cvs/xc/programs/Xserver/hw/xfree86/fbdevhw/fbdevhw.c,v
retrieving revision 1.19
diff -u -r1.19 fbdevhw.c
--- fbdevhw/fbdevhw.c 2000/09/26 15:57:17 1.19
+++ fbdevhw/fbdevhw.c 2000/10/09 22:09:33
@@ -43,7 +43,7 @@
MODINFOSTRING1,
MODINFOSTRING2,
XF86_VERSION_CURRENT,
- 0, 0, 1,
+ 0, 0, 2,
ABI_CLASS_VIDEODRV,
ABI_VIDEODRV_VERSION,
MOD_CLASS_NONE,
@@ -92,8 +92,10 @@
char* device;
int fd;
void* fbmem;
- int fboff;
- void* mmio;
+ unsigned intfbmem_len;
+ unsigned intfboff;
+ char* mmio;
+ unsigned intmmio_len;
/* current hardware state */
struct fb_fix_screeninfofix;
@@ -101,6 +103,8 @@
/* saved video mode */
struct fb_var_screeninfosaved_var;
+
+ /* FIXME: unused??? [geert] */
struct fb_cmap saved_cmap;
unsigned short *saved_red;
unsigned short *saved_green;
@@ -171,12 +175,9 @@
var->xres_virtual = pScrn->virtualX;
var->yres_virtual = pScrn->virtualY;
var->bits_per_pixel = pScrn->bitsPerPixel;
- var->red.length = 0;
- var->red.offset = 0;
- var->green.length = 0;
- var->green.offset = 0;
- var->blue.length= 0;
- var->blue.offset= 0;
+ var->red.length = pScrn->weight.red;
+ var->green.length = pScrn->weight.green;
+ var->blue.length= pScrn->weight.blue;
}
static void
@@ -256,28 +257,6 @@
/* */
/* open correct framebuffer device */
-static struct fb2pci_entry {
- CARD32 id;
- CARD32 vendor;
- CARD32 chip;
-} fb2pci_map[] = {
- { FB_ACCEL_MATROX_MGA2064W, PCI_VENDOR_MATROX, PCI_CHIP_MGA2064
},
- { FB_ACCEL_MATROX_MGA1064SG,PCI_VENDOR_MATROX, PCI_CHIP_MGA1064
},
- { FB_ACCEL_MATROX_MGA2164W, PCI_VENDOR_MATROX, PCI_CHIP_MGA2164
},
- { FB_ACCEL_MATROX_MGA2164W_AGP, PCI_VENDOR_MATROX, PCI_CHIP_MGA2164_AGP
},
- { FB_ACCEL_MATROX_MGAG100, PCI_VENDOR_MATROX, PCI_CHIP_MGAG100
},
- { FB_ACCEL_MATROX_MGAG200, PCI_VENDOR_MATROX, PCI_CHIP_MGAG200
},
- { FB_ACCEL_ATI_RAGE128, PCI_VENDOR_ATI,PCI_CHIP_RAGE128RE
},
- { FB_ACCEL_ATI_RAGE128, PCI_VENDOR_ATI,PCI_CHIP_RAGE128RF
},
- { FB_ACCEL_ATI_RAGE128, PCI_VENDOR_ATI,PCI_CHIP_RAGE128RK
},
- { FB_ACCEL_ATI_RAGE128, PCI_VENDOR_ATI,PCI_CHIP_RAGE128RL
},
- { FB_ACCEL_ATI_RAGE128, PCI_VENDOR_ATI,PCI_CHIP_RAGE128PF
},
- { FB_ACCEL_ATI_RAGE128, PCI_VENDOR_ATI,PCI_CHIP_RAGE128LE
},
- { FB_ACCEL_ATI_RAGE128, PCI_VENDOR_ATI,PCI_CHIP_RAGE128LF
},
- { FB_ACCEL_3DFX_BANSHEE,PCI_VENDOR_3DFX, PCI_CHIP_VOODOO3
},
-};
-#define FB2PCICOUNT (sizeof(fb2pci_map)/sizeof(struct fb2pci_entry))
-
/* try to find the framebuffer
[PATCH] fbdev fixes
Geert Uytterhoeven has helped me get some things right in the X 4.x fbdev code
finally:
depth and bpp are now passed correctly in both directions, the former encoded
in the r,g,b lengths.
Given a PCI ID, fbdev_open_pci now scans all the framebuffer devices'
framebuffer and MMIO regions to find the one which matches the PCI device. A
similar approach might be used to find and claim the PCI device for a given
framebuffer device, thus removing the need to explicitly specify the PCI ID
when using fbdev. As I don't fully understand the X PCI code though, review
and comments are greatly appreciated here.
The framebuffer and MMIO mapping should now also work correctly for strange
hardware with unaligned regions, fixing problems with the display being off
horizontally and the like.
The infamous 'FIXME: might be wrong' comment about the pScrn->displayWidth =
pScrn->virtualX; has also proved right; displayWidth can be any number of
bytes for a framebuffer device, but only a pixel aligned value for X, which
let me only fix it correctly when using ShadowFB. But it should work in most
cases even without. At least better than before ;)
Last but not least, the parameter for the FBIOBLANK ioctl had the wrong type,
but nobody noticed that I guess.
This has been successfully tested by me and a couple of other people. Feedback
always appreciated.
Michel
--
Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \ member of XFree86 and The DRI Project
Index: fbdevhw/fbdevhw.c
===
RCS file: /cvs/xc/programs/Xserver/hw/xfree86/fbdevhw/fbdevhw.c,v
retrieving revision 1.19
diff -u -r1.19 fbdevhw.c
--- fbdevhw/fbdevhw.c 2000/09/26 15:57:17 1.19
+++ fbdevhw/fbdevhw.c 2000/10/09 22:09:33
@@ -43,7 +43,7 @@
MODINFOSTRING1,
MODINFOSTRING2,
XF86_VERSION_CURRENT,
- 0, 0, 1,
+ 0, 0, 2,
ABI_CLASS_VIDEODRV,
ABI_VIDEODRV_VERSION,
MOD_CLASS_NONE,
@@ -92,8 +92,10 @@
char* device;
int fd;
void* fbmem;
- int fboff;
- void* mmio;
+ unsigned intfbmem_len;
+ unsigned intfboff;
+ char* mmio;
+ unsigned intmmio_len;
/* current hardware state */
struct fb_fix_screeninfofix;
@@ -101,6 +103,8 @@
/* saved video mode */
struct fb_var_screeninfosaved_var;
+
+ /* FIXME: unused??? [geert] */
struct fb_cmap saved_cmap;
unsigned short *saved_red;
unsigned short *saved_green;
@@ -171,12 +175,9 @@
var->xres_virtual = pScrn->virtualX;
var->yres_virtual = pScrn->virtualY;
var->bits_per_pixel = pScrn->bitsPerPixel;
- var->red.length = 0;
- var->red.offset = 0;
- var->green.length = 0;
- var->green.offset = 0;
- var->blue.length= 0;
- var->blue.offset= 0;
+ var->red.length = pScrn->weight.red;
+ var->green.length = pScrn->weight.green;
+ var->blue.length= pScrn->weight.blue;
}
static void
@@ -256,28 +257,6 @@
/* */
/* open correct framebuffer device */
-static struct fb2pci_entry {
- CARD32 id;
- CARD32 vendor;
- CARD32 chip;
-} fb2pci_map[] = {
- { FB_ACCEL_MATROX_MGA2064W, PCI_VENDOR_MATROX, PCI_CHIP_MGA2064 },
- { FB_ACCEL_MATROX_MGA1064SG,PCI_VENDOR_MATROX, PCI_CHIP_MGA1064 },
- { FB_ACCEL_MATROX_MGA2164W, PCI_VENDOR_MATROX, PCI_CHIP_MGA2164 },
- { FB_ACCEL_MATROX_MGA2164W_AGP, PCI_VENDOR_MATROX, PCI_CHIP_MGA2164_AGP },
- { FB_ACCEL_MATROX_MGAG100, PCI_VENDOR_MATROX, PCI_CHIP_MGAG100 },
- { FB_ACCEL_MATROX_MGAG200, PCI_VENDOR_MATROX, PCI_CHIP_MGAG200 },
- { FB_ACCEL_ATI_RAGE128, PCI_VENDOR_ATI,PCI_CHIP_RAGE128RE},
- { FB_ACCEL_ATI_RAGE128, PCI_VENDOR_ATI,PCI_CHIP_RAGE128RF},
- { FB_ACCEL_ATI_RAGE128, PCI_VENDOR_ATI,PCI_CHIP_RAGE128RK},
- { FB_ACCEL_ATI_RAGE128, PCI_VENDOR_ATI,PCI_CHIP_RAGE128RL},
- { FB_ACCEL_ATI_RAGE128, PCI_VENDOR_ATI,PCI_CHIP_RAGE128PF},
- { FB_ACCEL_ATI_RAGE128, PCI_VENDOR_ATI,PCI_CHIP_RAGE128LE},
- { FB_ACCEL_ATI_RAGE128, PCI_VENDOR_ATI,PCI_CHIP_RAGE128LF},
- { FB_ACCEL_3DFX_BANSHEE,PCI_VENDOR_3DFX, PCI_CHIP_VOODOO3 },
-};
-#define FB2PCICOUNT (sizeof(fb2pci_map)/sizeof(struct fb2pci_entry))
-
/* try to find the framebuffer device for
Re: Suggestion
>> Branden Robinson <[EMAIL PROTECTED]> writes: > I'm still apprehensive about moving *_dri.so out of > /usr/X11R6/lib/modules. If they aren't really X server modules, then > they don't belong in that directory (maybe /usr/lib/xlibmesa3 ?). > Should I ask upstream? I don't understand in what sense the dri modules aren't X server modules. For the case of direct rendering, an application is linked against the core GL library, which in talks to the hardware, the library part of the DRI or the library part of the DRM. The DRI talks to the DRM or to the X server (via the GLX protocol). The DRM talks to the kernel DRI module, which in turn talks to the hardware. The X server talks to its DRI module (these *_dri.so files) and/or the DRI driver on the X server, which talks to the hardware. The DRI module on the X server also talks to the kernel DRI module via the DRM library. This is also pretty much what happens for the case of a 2D application: the application talks to the Xlib which encodes the requests and sends them to the X server, which decodes them and passes whatever is appropiate to the XAA module which talks to the hardware. For indirect rendering, the application talks to the X server via the GLX protocol (there's no library talking to the hardware in this case). The server decodes the GLX requests and renders them appropriately (which means either via a software renderer, or a hw accelerated one). I'm not sure about the *current* DRI implementation (which is a shame, because *this* is the counter argument), but I *think* there's no hw acceleration for the indirect case. This means, the dri modules have to be shipped with the X server package, not with the GL library package. HTH, Marcelo
Re: backing store, and documentation
Here's a documentation patch based on my experimentation. Note: if I got anything wrong, that's reflected here. In particular, I'm bothered that Option BackingStore didn't work in the ServerFlags section -- I suspect that's either a mistake on my part or a bug in the implementation. [I'd go back and test, but I've been up all night and I need some sleep.] Thanks, -- Raul diff -c -r orig/XF86Config.5x new/XF86Config.5x *** orig/XF86Config.5x Mon Oct 9 14:51:59 2000 --- new/XF86Config.5x Mon Oct 9 14:56:18 2000 *** *** 1431,1437 options (described above) may be specified here, and ones given here override those given in the .B ServerFlags ! section. .PP The entries that may be used in this section are described here. .TP 7 --- 1431,1440 options (described above) may be specified here, and ones given here override those given in the .B ServerFlags ! section. Finally, there is a ! .B BackingStore ! option which by default is ! .BR off . .PP The entries that may be used in this section are described here. .TP 7 diff -c -r orig/Xserver.1x new/Xserver.1x *** orig/Xserver.1x Mon Oct 9 14:51:59 2000 --- new/Xserver.1x Mon Oct 9 14:56:48 2000 *** *** 90,97 previous releases (e.g., to work around bugs in R2 and R3 xterms and toolkits) . Deprecated. .TP 8 ! .B \-bs ! disables backing store support on all screens. .TP 8 .B \-c turns off key-click. --- 90,97 previous releases (e.g., to work around bugs in R2 and R3 xterms and toolkits) . Deprecated. .TP 8 ! .B \+bs ! enables backing store support on all screens. .TP 8 .B \-c turns off key-click. On Mon, Oct 09, 2000 at 02:27:34AM -0500, Branden Robinson wrote: > On Mon, Oct 09, 2000 at 01:03:03AM -0400, Raul Miller wrote: > > I just ran into something rather odd: I have an application which > > requires backing store. 4.0.1 has backing store off by default. > > > > You can turn on backing store by giving the x server the +bs option, > > or by putting > > option "backingstore" > > in the Screen section of XF86Config. > > > > This XF86Config option is undocumented, and the Xserver man page only > > documents the -bs option -- it doesn't mention the use of the "+" sign, > > nor does it mention that backing store is turned off by default. > > > > I don't know which is right -- the documentation or the implementation. > > The implementation, I believe. A patch to the XF86Config manpage and/or > the Xserver manpage would be welcome. > > -- > G. Branden Robinson |Somebody once asked me if I thought sex > Debian GNU/Linux|was dirty. I said, "It is if you're > [EMAIL PROTECTED] |doing it right." > http://www.debian.org/~branden/ |-- Woody Allen
Re: Suggestion
On Mon, Oct 09, 2000 at 11:20:37AM -0500, Branden Robinson wrote: > On Mon, Oct 09, 2000 at 09:17:05AM -0600, Joshua Shagam wrote: > > It's not the compiled code which has to match between DRI and DRM, > > just the interface. I'm using a DRM module compiled along with my > > 2.4.0-test8 kernel just fine with the precompiled mga.so and mga_dri.so > > which came in the X packages. After all, it all goes through a /dev/ > > interface - if the compilation had to match, then you'd have to recompile > > *all* your binaries whenever you recompile your kernel, and that makes > > absolutely no sense whatsoever. > > > > And since DRM is already distributed as part of the kernel, there's really > > no point in putting it in a separate package. :) > > Thanks for the good counterargument. > > I'm still apprehensive about moving *_dri.so out of /usr/X11R6/lib/modules. > If they aren't really X server modules, then they don't belong in that > directory (maybe /usr/lib/xlibmesa3 ?). Should I ask upstream? Ur, although they're separate files from the video drivers, aren't they considered part of the video driver? > > > Also very interresting, the mesa package (xlibmesa3) must also be > > > "compileable" whitout > > > compiling the whole X. > > > > Why? xlibmesa3 is part of the X server. It's based on Mesa, but it's not > > Mesa. > > Well, actually it is. It's just not generally the exact same version of > Mesa that the Mesa developers have released. (That and the fact that the X > build doesn't create libGLU yet.) Oh, I was under the impression that xlibmesa was more than just mesa (i.e. that it was the client-side libGL, which handled all the communication with the X server, be it through GLX or whatever). > > Isn't the current X server autodetection stuff good enough? > > Actually, it isn't. But I've written a program called "dexter" (which > replaces the old xserver-configure script) which does the prompting this > person wanted to see. Ah. > > I'm sure there'll eventually be (if there isn't already) XF86Setup for > > XFree 4, which will let people graphically mangle their conffiles once > > again... > > Yes, xf86cfg, but it is not complete yet. Can't be any worse than XF86Setup was. ;) -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email / \ Respect for open standards
Re: Suggestion
From: Sven Heyll <[EMAIL PROTECTED]> Subject: Suggestion Date: 09 Oct 2000 11:16:40 -0100 > Hi, > > why not splitting the xfree86-server package, so that the drm/dri stuff > is in an extra package and can be compiled before installing. Dri > modules have to be > compiled with the corresponding drm version, which is provided by the > kernel. I have been thinking about this and I think we should leave dri in xfree86-server and have the drm source (not dri) in a separate package. The device3dfx package is like this. It puts a few docs in /usr/share/doc and a source tar ball in /usr/src. You can unpack the tar ball go into the directory and type "make" and it builds the kernel module (3dfx.o in that case). I don't think it would be too hard to build such a package from the X sources. Almost every thing you would need is in the directory [X source]/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel you just need to package the Imake generated makefile and a few headers and source file from the parent directorys. This would also make so drm modules where not distributed with the kernel. Someone had said earlier that they did not want that. > I have kernel 2.4.0test6 and the X binarys forbid me to use dri. > I tried to compile (apt-get source xlib6g(or what ever) --compile) > X by myself, but this failed because of missing glide librarys. I dont > see the reason why > one would have to recompile whole X only to get DRI working. So one > possible solution > would be, that there is a > default DRI package, available also in binary version and compiled for > the current debian > kernel, or to let the user choose, during install of the binarypackage > to get and compile > and install the source package. This could be done after a test for the > kernel version. > This would become a mott point if drm and dri are both packaged in debian. The drm modules can be builded without building all of X. It takes some hacking, but I did it. And if we package it as I was saying above the package would contain "pre-hacked" source. So it could be built very easily. Dri and drm would both be upgraded when an upgrade happened and all someone would have to do is do a quick rebuild of the drms. These are all just ideas, of course. -Arthur
Re: Suggestion
> On Mon, Oct 09, 2000 at 09:17:05AM -0600, Joshua Shagam wrote: > > It's not the compiled code which has to match between DRI and DRM, > > just the interface. I'm using a DRM module compiled along with my > > 2.4.0-test8 kernel just fine with the precompiled mga.so and mga_dri.so > > which came in the X packages. After all, it all goes through a /dev/ > > interface - if the compilation had to match, then you'd have to recompile > > *all* your binaries whenever you recompile your kernel, and that makes > > absolutely no sense whatsoever. > > > > And since DRM is already distributed as part of the kernel, there's really > > no point in putting it in a separate package. : hmm I just got something wrong : I was not really sure (I know that now) where dri/drm modules modules came from ... there are kernel modules from my 2.4.0test6 kernel called "drm.o" "mga.o" "mga_drv.o" in /lib/modules.../drm/ and in the xserver-xfreee86 package there are some files called "/usr/X11R6/lib/modules/dri/mga_dri.so" and "/usr/X11R6/lib/modules/drivers/mga_drv.o". So I got confused what object file is what. I thought that it is redundant (mga_drv.o) . After all dri didnt work for me although I have a /proc/dri/0/ directory ... X said "(EE) MGA(0): [drm] MGADRIScreenInit failed (DRM version = 1.0.0, expected 2.0.x) . Disabling DRI." so I thought that there was a modules version mismatch ... I read the DRI Howto which said :"3D hardware acceleration requires a DRI kernel module that's specific to your graphics hardware. The DRI kernel module version must exactly match your running kernel version. Since there are so many versions of the kernel, it's difficult to provide precompiled kernel modules. " Maybe I dont need to enable drm in my kernel because X brings its own modules, but then they must match my kernel version, so I thought a seperate DRI package would be great. maybe I get it working, then I know that I was totally wrong and the current way of packing X is great. (Of course otherwise it is also great ) > > Thanks for the good counterargument. Yes thanks a lot. > > I'm still apprehensive about moving *_dri.so out of /usr/X11R6/lib/modules. > If they aren't really X server modules, then they don't belong in that > directory (maybe /usr/lib/xlibmesa3 ?). Should I ask upstream? > > > > Also very interresting, the mesa package (xlibmesa3) must also be > > > "compileable" whitout > > > compiling the whole X. > > > > Why? xlibmesa3 is part of the X server. It's based on Mesa, but it's not because of assembler optimising (not every CPU understands 3DNow! or MMX or even Pentium assembler. > > Mesa. > > Well, actually it is. It's just not generally the exact same version of > Mesa that the Mesa developers have released. (That and the fact that the X > build doesn't create libGLU yet.) > > > Isn't the current X server autodetection stuff good enough? > > Actually, it isn't. But I've written a program called "dexter" (which > replaces the old xserver-configure script) which does the prompting this > person wanted to see. cool ! > > > I'm sure there'll eventually be (if there isn't already) XF86Setup for > > XFree 4, which will let people graphically mangle their conffiles once > > again... > > Yes, xf86cfg, but it is not complete yet. I was thinking of a config tool to create the X make files (*.cf *.def etc) to be able to get a running ( mine isn't running yet ) and optimised X server and dri modules as well as mesa librarys. I am sorry if I got some of these things mixed up. thanks for the competent and quick answer. regards, Sven Heyll
Re: Suggestion
>> Branden Robinson <[EMAIL PROTECTED]> writes: > I'm still apprehensive about moving *_dri.so out of > /usr/X11R6/lib/modules. If they aren't really X server modules, then > they don't belong in that directory (maybe /usr/lib/xlibmesa3 ?). > Should I ask upstream? I don't understand in what sense the dri modules aren't X server modules. For the case of direct rendering, an application is linked against the core GL library, which in talks to the hardware, the library part of the DRI or the library part of the DRM. The DRI talks to the DRM or to the X server (via the GLX protocol). The DRM talks to the kernel DRI module, which in turn talks to the hardware. The X server talks to its DRI module (these *_dri.so files) and/or the DRI driver on the X server, which talks to the hardware. The DRI module on the X server also talks to the kernel DRI module via the DRM library. This is also pretty much what happens for the case of a 2D application: the application talks to the Xlib which encodes the requests and sends them to the X server, which decodes them and passes whatever is appropiate to the XAA module which talks to the hardware. For indirect rendering, the application talks to the X server via the GLX protocol (there's no library talking to the hardware in this case). The server decodes the GLX requests and renders them appropriately (which means either via a software renderer, or a hw accelerated one). I'm not sure about the *current* DRI implementation (which is a shame, because *this* is the counter argument), but I *think* there's no hw acceleration for the indirect case. This means, the dri modules have to be shipped with the X server package, not with the GL library package. HTH, Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: backing store, and documentation
Here's a documentation patch based on my experimentation. Note: if I got anything wrong, that's reflected here. In particular, I'm bothered that Option BackingStore didn't work in the ServerFlags section -- I suspect that's either a mistake on my part or a bug in the implementation. [I'd go back and test, but I've been up all night and I need some sleep.] Thanks, -- Raul diff -c -r orig/XF86Config.5x new/XF86Config.5x *** orig/XF86Config.5x Mon Oct 9 14:51:59 2000 --- new/XF86Config.5x Mon Oct 9 14:56:18 2000 *** *** 1431,1437 options (described above) may be specified here, and ones given here override those given in the .B ServerFlags ! section. .PP The entries that may be used in this section are described here. .TP 7 --- 1431,1440 options (described above) may be specified here, and ones given here override those given in the .B ServerFlags ! section. Finally, there is a ! .B BackingStore ! option which by default is ! .BR off . .PP The entries that may be used in this section are described here. .TP 7 diff -c -r orig/Xserver.1x new/Xserver.1x *** orig/Xserver.1x Mon Oct 9 14:51:59 2000 --- new/Xserver.1x Mon Oct 9 14:56:48 2000 *** *** 90,97 previous releases (e.g., to work around bugs in R2 and R3 xterms and toolkits) . Deprecated. .TP 8 ! .B \-bs ! disables backing store support on all screens. .TP 8 .B \-c turns off key-click. --- 90,97 previous releases (e.g., to work around bugs in R2 and R3 xterms and toolkits) . Deprecated. .TP 8 ! .B \+bs ! enables backing store support on all screens. .TP 8 .B \-c turns off key-click. On Mon, Oct 09, 2000 at 02:27:34AM -0500, Branden Robinson wrote: > On Mon, Oct 09, 2000 at 01:03:03AM -0400, Raul Miller wrote: > > I just ran into something rather odd: I have an application which > > requires backing store. 4.0.1 has backing store off by default. > > > > You can turn on backing store by giving the x server the +bs option, > > or by putting > > option "backingstore" > > in the Screen section of XF86Config. > > > > This XF86Config option is undocumented, and the Xserver man page only > > documents the -bs option -- it doesn't mention the use of the "+" sign, > > nor does it mention that backing store is turned off by default. > > > > I don't know which is right -- the documentation or the implementation. > > The implementation, I believe. A patch to the XF86Config manpage and/or > the Xserver manpage would be welcome. > > -- > G. Branden Robinson |Somebody once asked me if I thought sex > Debian GNU/Linux|was dirty. I said, "It is if you're > [EMAIL PROTECTED] |doing it right." > http://www.debian.org/~branden/ |-- Woody Allen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Suggestion
On Mon, Oct 09, 2000 at 09:17:05AM -0600, Joshua Shagam wrote: > It's not the compiled code which has to match between DRI and DRM, > just the interface. I'm using a DRM module compiled along with my > 2.4.0-test8 kernel just fine with the precompiled mga.so and mga_dri.so > which came in the X packages. After all, it all goes through a /dev/ > interface - if the compilation had to match, then you'd have to recompile > *all* your binaries whenever you recompile your kernel, and that makes > absolutely no sense whatsoever. > > And since DRM is already distributed as part of the kernel, there's really > no point in putting it in a separate package. :) Thanks for the good counterargument. I'm still apprehensive about moving *_dri.so out of /usr/X11R6/lib/modules. If they aren't really X server modules, then they don't belong in that directory (maybe /usr/lib/xlibmesa3 ?). Should I ask upstream? > > Also very interresting, the mesa package (xlibmesa3) must also be > > "compileable" whitout > > compiling the whole X. > > Why? xlibmesa3 is part of the X server. It's based on Mesa, but it's not > Mesa. Well, actually it is. It's just not generally the exact same version of Mesa that the Mesa developers have released. (That and the fact that the X build doesn't create libGLU yet.) > Isn't the current X server autodetection stuff good enough? Actually, it isn't. But I've written a program called "dexter" (which replaces the old xserver-configure script) which does the prompting this person wanted to see. > I'm sure there'll eventually be (if there isn't already) XF86Setup for > XFree 4, which will let people graphically mangle their conffiles once > again... Yes, xf86cfg, but it is not complete yet. -- G. Branden Robinson | "I came, I saw, she conquered." The Debian GNU/Linux| original Latin seems to have been [EMAIL PROTECTED] | garbled. http://www.debian.org/~branden/ | -- Robert Heinlein pgpkD4p2c0kr3.pgp Description: PGP signature
Re: Suggestion
On Mon, Oct 09, 2000 at 11:20:37AM -0500, Branden Robinson wrote: > On Mon, Oct 09, 2000 at 09:17:05AM -0600, Joshua Shagam wrote: > > It's not the compiled code which has to match between DRI and DRM, > > just the interface. I'm using a DRM module compiled along with my > > 2.4.0-test8 kernel just fine with the precompiled mga.so and mga_dri.so > > which came in the X packages. After all, it all goes through a /dev/ > > interface - if the compilation had to match, then you'd have to recompile > > *all* your binaries whenever you recompile your kernel, and that makes > > absolutely no sense whatsoever. > > > > And since DRM is already distributed as part of the kernel, there's really > > no point in putting it in a separate package. :) > > Thanks for the good counterargument. > > I'm still apprehensive about moving *_dri.so out of /usr/X11R6/lib/modules. > If they aren't really X server modules, then they don't belong in that > directory (maybe /usr/lib/xlibmesa3 ?). Should I ask upstream? Ur, although they're separate files from the video drivers, aren't they considered part of the video driver? > > > Also very interresting, the mesa package (xlibmesa3) must also be > > > "compileable" whitout > > > compiling the whole X. > > > > Why? xlibmesa3 is part of the X server. It's based on Mesa, but it's not > > Mesa. > > Well, actually it is. It's just not generally the exact same version of > Mesa that the Mesa developers have released. (That and the fact that the X > build doesn't create libGLU yet.) Oh, I was under the impression that xlibmesa was more than just mesa (i.e. that it was the client-side libGL, which handled all the communication with the X server, be it through GLX or whatever). > > Isn't the current X server autodetection stuff good enough? > > Actually, it isn't. But I've written a program called "dexter" (which > replaces the old xserver-configure script) which does the prompting this > person wanted to see. Ah. > > I'm sure there'll eventually be (if there isn't already) XF86Setup for > > XFree 4, which will let people graphically mangle their conffiles once > > again... > > Yes, xf86cfg, but it is not complete yet. Can't be any worse than XF86Setup was. ;) -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email / \ Respect for open standards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Suggestion
From: Sven Heyll <[EMAIL PROTECTED]> Subject: Suggestion Date: 09 Oct 2000 11:16:40 -0100 > Hi, > > why not splitting the xfree86-server package, so that the drm/dri stuff > is in an extra package and can be compiled before installing. Dri > modules have to be > compiled with the corresponding drm version, which is provided by the > kernel. I have been thinking about this and I think we should leave dri in xfree86-server and have the drm source (not dri) in a separate package. The device3dfx package is like this. It puts a few docs in /usr/share/doc and a source tar ball in /usr/src. You can unpack the tar ball go into the directory and type "make" and it builds the kernel module (3dfx.o in that case). I don't think it would be too hard to build such a package from the X sources. Almost every thing you would need is in the directory [X source]/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel you just need to package the Imake generated makefile and a few headers and source file from the parent directorys. This would also make so drm modules where not distributed with the kernel. Someone had said earlier that they did not want that. > I have kernel 2.4.0test6 and the X binarys forbid me to use dri. > I tried to compile (apt-get source xlib6g(or what ever) --compile) > X by myself, but this failed because of missing glide librarys. I dont > see the reason why > one would have to recompile whole X only to get DRI working. So one > possible solution > would be, that there is a > default DRI package, available also in binary version and compiled for > the current debian > kernel, or to let the user choose, during install of the binarypackage > to get and compile > and install the source package. This could be done after a test for the > kernel version. > This would become a mott point if drm and dri are both packaged in debian. The drm modules can be builded without building all of X. It takes some hacking, but I did it. And if we package it as I was saying above the package would contain "pre-hacked" source. So it could be built very easily. Dri and drm would both be upgraded when an upgrade happened and all someone would have to do is do a quick rebuild of the drms. These are all just ideas, of course. -Arthur -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Suggestion
> On Mon, Oct 09, 2000 at 09:17:05AM -0600, Joshua Shagam wrote: > > It's not the compiled code which has to match between DRI and DRM, > > just the interface. I'm using a DRM module compiled along with my > > 2.4.0-test8 kernel just fine with the precompiled mga.so and mga_dri.so > > which came in the X packages. After all, it all goes through a /dev/ > > interface - if the compilation had to match, then you'd have to recompile > > *all* your binaries whenever you recompile your kernel, and that makes > > absolutely no sense whatsoever. > > > > And since DRM is already distributed as part of the kernel, there's really > > no point in putting it in a separate package. : hmm I just got something wrong : I was not really sure (I know that now) where dri/drm modules modules came from ... there are kernel modules from my 2.4.0test6 kernel called "drm.o" "mga.o" "mga_drv.o" in /lib/modules.../drm/ and in the xserver-xfreee86 package there are some files called "/usr/X11R6/lib/modules/dri/mga_dri.so" and "/usr/X11R6/lib/modules/drivers/mga_drv.o". So I got confused what object file is what. I thought that it is redundant (mga_drv.o) . After all dri didnt work for me although I have a /proc/dri/0/ directory ... X said "(EE) MGA(0): [drm] MGADRIScreenInit failed (DRM version = 1.0.0, expected 2.0.x) . Disabling DRI." so I thought that there was a modules version mismatch ... I read the DRI Howto which said :"3D hardware acceleration requires a DRI kernel module that's specific to your graphics hardware. The DRI kernel module version must exactly match your running kernel version. Since there are so many versions of the kernel, it's difficult to provide precompiled kernel modules. " Maybe I dont need to enable drm in my kernel because X brings its own modules, but then they must match my kernel version, so I thought a seperate DRI package would be great. maybe I get it working, then I know that I was totally wrong and the current way of packing X is great. (Of course otherwise it is also great ) > > Thanks for the good counterargument. Yes thanks a lot. > > I'm still apprehensive about moving *_dri.so out of /usr/X11R6/lib/modules. > If they aren't really X server modules, then they don't belong in that > directory (maybe /usr/lib/xlibmesa3 ?). Should I ask upstream? > > > > Also very interresting, the mesa package (xlibmesa3) must also be > > > "compileable" whitout > > > compiling the whole X. > > > > Why? xlibmesa3 is part of the X server. It's based on Mesa, but it's not because of assembler optimising (not every CPU understands 3DNow! or MMX or even Pentium assembler. > > Mesa. > > Well, actually it is. It's just not generally the exact same version of > Mesa that the Mesa developers have released. (That and the fact that the X > build doesn't create libGLU yet.) > > > Isn't the current X server autodetection stuff good enough? > > Actually, it isn't. But I've written a program called "dexter" (which > replaces the old xserver-configure script) which does the prompting this > person wanted to see. cool ! > > > I'm sure there'll eventually be (if there isn't already) XF86Setup for > > XFree 4, which will let people graphically mangle their conffiles once > > again... > > Yes, xf86cfg, but it is not complete yet. I was thinking of a config tool to create the X make files (*.cf *.def etc) to be able to get a running ( mine isn't running yet ) and optimised X server and dri modules as well as mesa librarys. I am sorry if I got some of these things mixed up. thanks for the competent and quick answer. regards, Sven Heyll -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Suggestion
On Mon, Oct 09, 2000 at 11:16:40AM -0100, Sven Heyll wrote:
> Hi,
>
> why not splitting the xfree86-server package, so that the drm/dri stuff
> is in an extra package and can be compiled before installing. Dri
> modules have to be
> compiled with the corresponding drm version, which is provided by the
> kernel.
> I have kernel 2.4.0test6 and the X binarys forbid me to use dri.
> I tried to compile (apt-get source xlib6g(or what ever) --compile)
> X by myself, but this failed because of missing glide librarys. I dont
> see the reason why
> one would have to recompile whole X only to get DRI working. So one
> possible solution
> would be, that there is a
> default DRI package, available also in binary version and compiled for
> the current debian
> kernel, or to let the user choose, during install of the binarypackage
> to get and compile
> and install the source package. This could be done after a test for the
> kernel version.
And, of course, it could be setup as a make-kpkg module package (like
alsa-source. But:
It's not the compiled code which has to match between DRI and DRM,
just the interface. I'm using a DRM module compiled along with my
2.4.0-test8 kernel just fine with the precompiled mga.so and mga_dri.so
which came in the X packages. After all, it all goes through a /dev/
interface - if the compilation had to match, then you'd have to recompile
*all* your binaries whenever you recompile your kernel, and that makes
absolutely no sense whatsoever.
And since DRM is already distributed as part of the kernel, there's really
no point in putting it in a separate package. :)
> Also very interresting, the mesa package (xlibmesa3) must also be
> "compileable" whitout
> compiling the whole X.
Why? xlibmesa3 is part of the X server. It's based on Mesa, but it's not
Mesa.
> Maybe this causes the need for a virtual package which containts a
> script that interactivly generates
> the right configfiles and installs them in the source directoy of X
> parts( like mesa, dri ...).
> This package contains debian specific config file
> templates ("xc/config/.../host.def" ... etc) and
> perl script may askyou quesations like "Do you have a < ...> card
> ?" "Should <...> be activated ?" etc
> very simple and basic.
Isn't the current X server autodetection stuff good enough? I'm sure
there'll eventually be (if there isn't already) XF86Setup for XFree 4,
which will let people graphically mangle their conffiles once again...
--
Joshua Shagam /"\ ASCII Ribbon Campaign
[EMAIL PROTECTED] \ / No HTML/RTF in email
www.cs.nmsu.edu/~joshagam X No Word docs in email
/ \ Respect for open standards
Re: Suggestion
On Mon, Oct 09, 2000 at 09:17:05AM -0600, Joshua Shagam wrote: > It's not the compiled code which has to match between DRI and DRM, > just the interface. I'm using a DRM module compiled along with my > 2.4.0-test8 kernel just fine with the precompiled mga.so and mga_dri.so > which came in the X packages. After all, it all goes through a /dev/ > interface - if the compilation had to match, then you'd have to recompile > *all* your binaries whenever you recompile your kernel, and that makes > absolutely no sense whatsoever. > > And since DRM is already distributed as part of the kernel, there's really > no point in putting it in a separate package. :) Thanks for the good counterargument. I'm still apprehensive about moving *_dri.so out of /usr/X11R6/lib/modules. If they aren't really X server modules, then they don't belong in that directory (maybe /usr/lib/xlibmesa3 ?). Should I ask upstream? > > Also very interresting, the mesa package (xlibmesa3) must also be > > "compileable" whitout > > compiling the whole X. > > Why? xlibmesa3 is part of the X server. It's based on Mesa, but it's not > Mesa. Well, actually it is. It's just not generally the exact same version of Mesa that the Mesa developers have released. (That and the fact that the X build doesn't create libGLU yet.) > Isn't the current X server autodetection stuff good enough? Actually, it isn't. But I've written a program called "dexter" (which replaces the old xserver-configure script) which does the prompting this person wanted to see. > I'm sure there'll eventually be (if there isn't already) XF86Setup for > XFree 4, which will let people graphically mangle their conffiles once > again... Yes, xf86cfg, but it is not complete yet. -- G. Branden Robinson | "I came, I saw, she conquered." The Debian GNU/Linux| original Latin seems to have been [EMAIL PROTECTED] | garbled. http://www.debian.org/~branden/ | -- Robert Heinlein PGP signature
Re: Suggestion
On Mon, Oct 09, 2000 at 11:16:40AM -0100, Sven Heyll wrote:
> Hi,
>
> why not splitting the xfree86-server package, so that the drm/dri stuff
> is in an extra package and can be compiled before installing. Dri
> modules have to be
> compiled with the corresponding drm version, which is provided by the
> kernel.
> I have kernel 2.4.0test6 and the X binarys forbid me to use dri.
> I tried to compile (apt-get source xlib6g(or what ever) --compile)
> X by myself, but this failed because of missing glide librarys. I dont
> see the reason why
> one would have to recompile whole X only to get DRI working. So one
> possible solution
> would be, that there is a
> default DRI package, available also in binary version and compiled for
> the current debian
> kernel, or to let the user choose, during install of the binarypackage
> to get and compile
> and install the source package. This could be done after a test for the
> kernel version.
And, of course, it could be setup as a make-kpkg module package (like
alsa-source. But:
It's not the compiled code which has to match between DRI and DRM,
just the interface. I'm using a DRM module compiled along with my
2.4.0-test8 kernel just fine with the precompiled mga.so and mga_dri.so
which came in the X packages. After all, it all goes through a /dev/
interface - if the compilation had to match, then you'd have to recompile
*all* your binaries whenever you recompile your kernel, and that makes
absolutely no sense whatsoever.
And since DRM is already distributed as part of the kernel, there's really
no point in putting it in a separate package. :)
> Also very interresting, the mesa package (xlibmesa3) must also be
> "compileable" whitout
> compiling the whole X.
Why? xlibmesa3 is part of the X server. It's based on Mesa, but it's not
Mesa.
> Maybe this causes the need for a virtual package which containts a
> script that interactivly generates
> the right configfiles and installs them in the source directoy of X
> parts( like mesa, dri ...).
> This package contains debian specific config file
> templates ("xc/config/.../host.def" ... etc) and
> perl script may askyou quesations like "Do you have a < ...> card
> ?" "Should <...> be activated ?" etc
> very simple and basic.
Isn't the current X server autodetection stuff good enough? I'm sure
there'll eventually be (if there isn't already) XF86Setup for XFree 4,
which will let people graphically mangle their conffiles once again...
--
Joshua Shagam /"\ ASCII Ribbon Campaign
[EMAIL PROTECTED] \ / No HTML/RTF in email
www.cs.nmsu.edu/~joshagam X No Word docs in email
/ \ Respect for open standards
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Suggestion
Hi,
why not splitting the xfree86-server package, so that the drm/dri stuff
is in an extra package and can be compiled before installing. Dri
modules have to be
compiled with the corresponding drm version, which is provided by the
kernel.
I have kernel 2.4.0test6 and the X binarys forbid me to use dri.
I tried to compile (apt-get source xlib6g(or what ever) --compile)
X by myself, but this failed because of missing glide librarys. I dont
see the reason why
one would have to recompile whole X only to get DRI working. So one
possible solution
would be, that there is a
default DRI package, available also in binary version and compiled for
the current debian
kernel, or to let the user choose, during install of the binarypackage
to get and compile
and install the source package. This could be done after a test for the
kernel version.
Also very interresting, the mesa package (xlibmesa3) must also be
"compileable" whitout
compiling the whole X.
Maybe this causes the need for a virtual package which containts a
script that interactivly generates
the right configfiles and installs them in the source directoy of X
parts( like mesa, dri ...).
This package contains debian specific config file
templates ("xc/config/.../host.def" ... etc) and
perl script may askyou quesations like "Do you have a < ...> card
?" "Should <...> be activated ?" etc
very simple and basic.
Just a suggestion,
regards Sven Heyll
Suggestion
Hi,
why not splitting the xfree86-server package, so that the drm/dri stuff
is in an extra package and can be compiled before installing. Dri
modules have to be
compiled with the corresponding drm version, which is provided by the
kernel.
I have kernel 2.4.0test6 and the X binarys forbid me to use dri.
I tried to compile (apt-get source xlib6g(or what ever) --compile)
X by myself, but this failed because of missing glide librarys. I dont
see the reason why
one would have to recompile whole X only to get DRI working. So one
possible solution
would be, that there is a
default DRI package, available also in binary version and compiled for
the current debian
kernel, or to let the user choose, during install of the binarypackage
to get and compile
and install the source package. This could be done after a test for the
kernel version.
Also very interresting, the mesa package (xlibmesa3) must also be
"compileable" whitout
compiling the whole X.
Maybe this causes the need for a virtual package which containts a
script that interactivly generates
the right configfiles and installs them in the source directoy of X
parts( like mesa, dri ...).
This package contains debian specific config file
templates ("xc/config/.../host.def" ... etc) and
perl script may askyou quesations like "Do you have a < ...> card
?" "Should <...> be activated ?" etc
very simple and basic.
Just a suggestion,
regards Sven Heyll
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: TrueType fonts without xfstt
On Sun, Oct 08, 2000 at 05:50:33PM +0200, Christian Hammers wrote: > Thanks for that hint, ttmkfdir was the right thing to use. > > Branden, can you include this into the new X server and maybe even give > a short hint how to use it in somewhere in /usr/share/doc. > The license is no problem, it's copyrighted by "The XFree86 Project" and > written by Joerg Pommnitz (given email is invalid). This is yet another issue they're arguing about upstream. IIRC some folks want it in, but Juliusz Chroboczek doesn't because it's written in C++. -- G. Branden Robinson | Debian GNU/Linux| Mob rule isn't any prettier just because [EMAIL PROTECTED] | you call your mob a government. http://www.debian.org/~branden/ | pgpQWCZh9cfOD.pgp Description: PGP signature
Re: backing store, and documentation
On Mon, Oct 09, 2000 at 01:03:03AM -0400, Raul Miller wrote: > I just ran into something rather odd: I have an application which > requires backing store. 4.0.1 has backing store off by default. > > You can turn on backing store by giving the x server the +bs option, > or by putting > option "backingstore" > in the Screen section of XF86Config. > > This XF86Config option is undocumented, and the Xserver man page only > documents the -bs option -- it doesn't mention the use of the "+" sign, > nor does it mention that backing store is turned off by default. > > I don't know which is right -- the documentation or the implementation. The implementation, I believe. A patch to the XF86Config manpage and/or the Xserver manpage would be welcome. -- G. Branden Robinson |Somebody once asked me if I thought sex Debian GNU/Linux|was dirty. I said, "It is if you're [EMAIL PROTECTED] |doing it right." http://www.debian.org/~branden/ |-- Woody Allen pgpeDC8V39JbW.pgp Description: PGP signature
Re: TrueType fonts without xfstt
On Sun, Oct 08, 2000 at 05:50:33PM +0200, Christian Hammers wrote: > Thanks for that hint, ttmkfdir was the right thing to use. > > Branden, can you include this into the new X server and maybe even give > a short hint how to use it in somewhere in /usr/share/doc. > The license is no problem, it's copyrighted by "The XFree86 Project" and > written by Joerg Pommnitz (given email is invalid). This is yet another issue they're arguing about upstream. IIRC some folks want it in, but Juliusz Chroboczek doesn't because it's written in C++. -- G. Branden Robinson | Debian GNU/Linux| Mob rule isn't any prettier just because [EMAIL PROTECTED] | you call your mob a government. http://www.debian.org/~branden/ | PGP signature
Re: backing store, and documentation
On Mon, Oct 09, 2000 at 01:03:03AM -0400, Raul Miller wrote: > I just ran into something rather odd: I have an application which > requires backing store. 4.0.1 has backing store off by default. > > You can turn on backing store by giving the x server the +bs option, > or by putting > option "backingstore" > in the Screen section of XF86Config. > > This XF86Config option is undocumented, and the Xserver man page only > documents the -bs option -- it doesn't mention the use of the "+" sign, > nor does it mention that backing store is turned off by default. > > I don't know which is right -- the documentation or the implementation. The implementation, I believe. A patch to the XF86Config manpage and/or the Xserver manpage would be welcome. -- G. Branden Robinson |Somebody once asked me if I thought sex Debian GNU/Linux|was dirty. I said, "It is if you're [EMAIL PROTECTED] |doing it right." http://www.debian.org/~branden/ |-- Woody Allen PGP signature
backing store, and documentation
I just ran into something rather odd: I have an application which requires backing store. 4.0.1 has backing store off by default. You can turn on backing store by giving the x server the +bs option, or by putting option "backingstore" in the Screen section of XF86Config. This XF86Config option is undocumented, and the Xserver man page only documents the -bs option -- it doesn't mention the use of the "+" sign, nor does it mention that backing store is turned off by default. I don't know which is right -- the documentation or the implementation. -- Raul
