Re: cvs compile failed: fbdev
Marc Aurele La France wrote: They came straigt from linux-2.6.9rc1. I realized that the cvs compiles fine with linux-2.4, but not the fbdev doesn't compile under 2.6.9rc1. rc1 inserts a pointer to kernel memory into the middle of the fb_monspecs structure. So, either more of linux/fb.h needs to bracketed with #ifndef __KERNEL__, or rc1 breaks userland binary compatibility (among other things). In both cases, this is a kernel issue. They will tell you it's not: /usr/include/linux/list.h:700: warning: #warning don't include kernel headers in userspace I don't know how to handle this properly, though. -Michael ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: cvs compile failed: fbdev
Marc Aurele La France wrote: ... In both cases, this is a kernel issue. They will tell you it's not: /usr/include/linux/list.h:700: warning: #warning don't include kernel headers in userspace Irrelevant. The #include linux/list.h is only there in an attempt to resolve the type of the inserted kernel memory list pointer. I don't know how to handle this properly, though. Don't assume problems with test kernels need to be resolved here. You didn't get it. Including linux kernel headers in user space is a no no. See various threads about this on LKML. Bottom line: If you include kernel headers and your app breaks it's your fault not ours. -Michael ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Xv and resolution loss on matrox cards
David Dawes wrote: Isn't the 'accelerated 2x horizontal zoom' thing something that is required (because of hardware limitation) above certain clock rates? I don't have the relevant specs handy to check. This seems to be irrelevant in practice. With my G400 at [EMAIL PROTECTED], 32 bpp (max my monitor can do) I could provoke some slight image distortion (occasional single black lines in the overlay) by running mplayer, glxgears and 'ls -lR /' in an xterm in parallel -- maybe there are better test cases. This seems to demonstrate some bandwidth limitation, but it doesn't occur in normal cases. At [EMAIL PROTECTED], 32 bpp what I normally use I can't see anything at all. So, because I don't have any specs (and if the numbers currently in the code are derived from specs they are way too conservative) and prefer a good image under normal circumstances to a bad one all the time, I followed mga_vid's example and ripped the whole thing out. -Michael ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Xv and resolution loss on matrox cards
Seems like the BES regs are double bufferd, therefore commit them
_after_ they are set. New patch:
Index: programs/Xserver/hw/xfree86/drivers/mga/mga_video.c
===
RCS file: /cvs/xc/programs/Xserver/hw/xfree86/drivers/mga/mga_video.c,v
retrieving revision 1.34
diff -u -r1.34 mga_video.c
--- programs/Xserver/hw/xfree86/drivers/mga/mga_video.c 20 Feb 2004 16:59:49 -
1.34
+++ programs/Xserver/hw/xfree86/drivers/mga/mga_video.c 16 Apr 2004 17:09:29 -
@@ -578,48 +578,19 @@
short src_w, short src_h,
short drw_w, short drw_h
){
+#define VSYNC_POS 2
+
MGAPtr pMga = MGAPTR(pScrn);
-int tmp, hzoom, intrep;
-int maxOverlayClock;
+int tmp, intrep;
CHECK_DMA_QUIESCENT(pMga, pScrn);
-/* got 48 scanlines to do it in */
-tmp = INREG(MGAREG_VCOUNT) + 48;
-/* FIXME always change it in vertical retrace use CrtcV ?*/
-if(tmp pScrn-currentMode-CrtcVTotal)
- tmp -= 49; /* too bad */
-else
-tmp = pScrn-currentMode-CrtcVTotal -1;
-
-tmp = pScrn-currentMode-VDisplay +1;
-/* enable accelerated 2x horizontal zoom when pixelclock 135MHz */
-
-if ((pMga-ChipRev = 0x80) || (pMga-Chipset == PCI_CHIP_MGAG550)) {
- /* G450, G550 */
- maxOverlayClock = 234000;
-} else {
- maxOverlayClock = 135000;
-}
-
-hzoom = (pScrn-currentMode-Clock maxOverlayClock) ? 1 : 0;
-
-switch(id) {
-case FOURCC_UYVY:
- OUTREG(MGAREG_BESGLOBCTL, 0x00c0 | (3 * hzoom) | (tmp 16));
- break;
-case FOURCC_YUY2:
-default:
- OUTREG(MGAREG_BESGLOBCTL, 0x0080 | (3 * hzoom) | (tmp 16));
- break;
-}
-
OUTREG(MGAREG_BESA1ORG, offset);
if(y1 0x0001)
- OUTREG(MGAREG_BESCTL, 0x00040c41);
+ OUTREG(MGAREG_BESCTL, 0x00050c41);
else
- OUTREG(MGAREG_BESCTL, 0x00040c01);
+ OUTREG(MGAREG_BESCTL, 0x00050c01);
OUTREG(MGAREG_BESHCOORD, (dstBox-x1 16) | (dstBox-x2 - 1));
OUTREG(MGAREG_BESVCOORD, (dstBox-y1 16) | (dstBox-y2 - 1));
@@ -640,11 +611,20 @@
OUTREG(MGAREG_BESVISCAL, tmp 0x001c);
intrep = ((drw_w == src_w) || (drw_w 2)) ? 0 : 1;
-tmp = (((src_w - intrep) 16)/(drw_w - intrep)) hzoom;
+tmp = (((src_w - intrep) 16)/(drw_w - intrep));
if(tmp = (32 16))
tmp = (32 16) - 1;
OUTREG(MGAREG_BESHISCAL, tmp 0x001c);
+switch(id) {
+case FOURCC_UYVY:
+ OUTREG(MGAREG_BESGLOBCTL, 0x00c0 | (VSYNC_POS 16));
+ break;
+case FOURCC_YUY2:
+default:
+ OUTREG(MGAREG_BESGLOBCTL, 0x0080 | (VSYNC_POS 16));
+ break;
+}
}
static void
Xv and resolution loss on matrox cards
I'm rehashing an old thread from xpert,
http://marc.theaimsgroup.com/?t=9772209053r=1w=2 and propose the
following patch, derived from how mga_vid.c (kernel module for Matrox
BES from mplayer) programs the card. It basically disables that
'accelerated 2x horizontal zoom' thing which causes the problem. (With
this option on, it looks like information from only every other pixel is
used.)
It also turns back on 'chroma upsampling' (which was only turned off in
a failed attempt to solve the issue, see quoted thread) and changes the
vsync position to 2 (a la mga_vid.c, seems as good a constant as what
was used before but is simpler).
A good example for testing is
http://cox.iwr.uni-heidelberg.de/~ug/films/stefan.mov
-Michael
Index: programs/Xserver/hw/xfree86/drivers/mga/mga_video.c
===
RCS file: /cvs/xc/programs/Xserver/hw/xfree86/drivers/mga/mga_video.c,v
retrieving revision 1.34
diff -u -r1.34 mga_video.c
--- programs/Xserver/hw/xfree86/drivers/mga/mga_video.c 20 Feb 2004 16:59:49 -
1.34
+++ programs/Xserver/hw/xfree86/drivers/mga/mga_video.c 15 Apr 2004 12:35:35 -
@@ -578,48 +578,29 @@
short src_w, short src_h,
short drw_w, short drw_h
){
+#define VSYNC_POS 2
+
MGAPtr pMga = MGAPTR(pScrn);
-int tmp, hzoom, intrep;
-int maxOverlayClock;
+int tmp, intrep;
CHECK_DMA_QUIESCENT(pMga, pScrn);
-/* got 48 scanlines to do it in */
-tmp = INREG(MGAREG_VCOUNT) + 48;
-/* FIXME always change it in vertical retrace use CrtcV ?*/
-if(tmp pScrn-currentMode-CrtcVTotal)
- tmp -= 49; /* too bad */
-else
-tmp = pScrn-currentMode-CrtcVTotal -1;
-
-tmp = pScrn-currentMode-VDisplay +1;
-/* enable accelerated 2x horizontal zoom when pixelclock 135MHz */
-
-if ((pMga-ChipRev = 0x80) || (pMga-Chipset == PCI_CHIP_MGAG550)) {
- /* G450, G550 */
- maxOverlayClock = 234000;
-} else {
- maxOverlayClock = 135000;
-}
-
-hzoom = (pScrn-currentMode-Clock maxOverlayClock) ? 1 : 0;
-
switch(id) {
case FOURCC_UYVY:
- OUTREG(MGAREG_BESGLOBCTL, 0x00c0 | (3 * hzoom) | (tmp 16));
+ OUTREG(MGAREG_BESGLOBCTL, 0x00c0 | (VSYNC_POS 16));
break;
case FOURCC_YUY2:
default:
- OUTREG(MGAREG_BESGLOBCTL, 0x0080 | (3 * hzoom) | (tmp 16));
+ OUTREG(MGAREG_BESGLOBCTL, 0x0080 | (VSYNC_POS 16));
break;
}
OUTREG(MGAREG_BESA1ORG, offset);
if(y1 0x0001)
- OUTREG(MGAREG_BESCTL, 0x00040c41);
+ OUTREG(MGAREG_BESCTL, 0x00050c41);
else
- OUTREG(MGAREG_BESCTL, 0x00040c01);
+ OUTREG(MGAREG_BESCTL, 0x00050c01);
OUTREG(MGAREG_BESHCOORD, (dstBox-x1 16) | (dstBox-x2 - 1));
OUTREG(MGAREG_BESVCOORD, (dstBox-y1 16) | (dstBox-y2 - 1));
@@ -640,7 +621,7 @@
OUTREG(MGAREG_BESVISCAL, tmp 0x001c);
intrep = ((drw_w == src_w) || (drw_w 2)) ? 0 : 1;
-tmp = (((src_w - intrep) 16)/(drw_w - intrep)) hzoom;
+tmp = (((src_w - intrep) 16)/(drw_w - intrep));
if(tmp = (32 16))
tmp = (32 16) - 1;
OUTREG(MGAREG_BESHISCAL, tmp 0x001c);
Re: External FreeType build problem
David Dawes wrote: Do the gcc people give a reason for not allowing a system directory to be blessed with -I? I wouldn't call it a reason, but the manual puts it like this: (...) the option is ignored to ensure that the default search order for system directories and the special treatment of system headers are not defeated. OK, I see. This is to prevent system directories being searched before directories containing gcc-specific replacements for system headers. Even worse. Current CVS fails to build xterm with gcc 2.95.3 because of this '-I/usr/include': gcc -c -O2 -march=i686 -fomit-frame-pointer -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -I../../exports/include -I/usr/include -I/usr/include/freetype2 -I../../exports/include/X11 -I../.. -I../../exports/include -I../../exports/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DNO_MESSAGE_CATALOG -DFUNCPROTO=15 -DNARROWPROTO -I. -DSCROLLBAR_RIGHT -DOPT_WIDE_CHARS -DOPT_LUIT_PROG -DXRENDERFONT -DXFREE86_FT2 -DPROJECTROOT=/opt/XFree86-4.4charproc.c In file included from charproc.c:123: /usr/include/error.h:26: parse error This is because gcc now includes /usr/include/error.h instead of error.h from programs/xterm. One should never put an explicit '-I/usr/include' or '-I/usr/local/include' in CFLAGS because this can lead to all sorts of strange behaviour. The same holds for '-L/usr/lib' or '-L/usr/local/lib' in LDFLAGS. Michael ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: External FreeType build problem
David Dawes wrote:
Even worse. Current CVS fails to build xterm with gcc 2.95.3 because of
this '-I/usr/include':
gcc -c -O2 -march=i686 -fomit-frame-pointer -ansi -pedantic -Wall
-Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef
-I../../exports/include -I/usr/include -I/usr/include/freetype2
-I../../exports/include/X11 -I../.. -I../../exports/include
-I../../exports/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L
-D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE
-D_GNU_SOURCE -DNO_MESSAGE_CATALOG -DFUNCPROTO=15 -DNARROWPROTO -I.
-DSCROLLBAR_RIGHT -DOPT_WIDE_CHARS -DOPT_LUIT_PROG -DXRENDERFONT
-DXFREE86_FT2 -DPROJECTROOT=/opt/XFree86-4.4charproc.c
In file included from charproc.c:123:
/usr/include/error.h:26: parse error
This is because gcc now includes /usr/include/error.h instead of error.h
from programs/xterm.
One should never put an explicit '-I/usr/include' or
'-I/usr/local/include' in CFLAGS because this can lead to all sorts of
strange behaviour.
Never /usr/local/include?? That's ridiculous. How are you deciding which
ones are allowed and which are not?
The point is (I'm refering to gcc here) that /usr/local/include and
/usr/include are searched by default but in this order:
explicitly given includes first
/usr/local/include
/usr/lib/gcc-lib/i486-linux/2.95.3/../../../../i486-linux/include
/usr/lib/gcc-lib/i486-linux/2.95.3/include
/usr/include
In this order you normally get what you expect. For example, if you have
a more recent version of some library installed in /usr/local than in
/usr. Putting '-I/usr/include' in CFLAGS changes this order and produces
unexpected results, especially if you don't do it yourself but some
'foo-config --clags'. Another example is the above xterm build error.
I think this is the real reason why newer gcc's simply ignore
'-I/usr/include'
Besides, most sane 'foo-config' scripts contain for that very reason
something like this:
- from freetype-config -
if test $echo_cflags = yes ; then
cflags=-I${prefix}/include/freetype2
if test ${prefix}/include != /usr/include ; then ==
echo -I${prefix}/include $cflags
else
echo $cflags
fi
fi
if test $echo_libs = yes ; then
libs=-lfreetype -lz
if test ${exec_prefix}/lib != /usr/lib ; then ==
echo -L${exec_prefix}/lib $libs
else
echo $libs
fi
fi
-
'-I/usr/local/include' and '-L/usr/local/lib' seem, on second thought,
not to be a problem.
If you use these and have local headers that might conflict,
I guess every unix has /usr/include/error.h
then
you must put -I. in explicitly first. Then there is no ambiguity.
I'd say that's what needs to happen for xterm/Imakefile.
Would obviously solve the xterm build problem. As would removing
'-I/usr/include'.
If someone wants to try builds that currently rely on -I/usr/include and
make sure they work correctly when they are removed, please do, and send
reports of any problems.
Which systems do not search in /usr/include automatically?
Michael
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
