From owner-freebsd-x11@FreeBSD.ORG Sun Jan 9 11:54:54 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7EB5416A4CF for ; Sun, 9 Jan 2005 11:54:54 +0000 (GMT) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C8C343D31 for ; Sun, 9 Jan 2005 11:54:53 +0000 (GMT) (envelope-from oliver@FreeBSD.org) Received: (qmail 89875 invoked by uid 89); 9 Jan 2005 11:53:32 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 9 Jan 2005 11:53:32 -0000 Date: Sun, 9 Jan 2005 12:55:01 +0100 From: Oliver Lehmann To: freebsd-gnats-submit@FreeBSD.org Message-Id: <20050109125501.3b4af9de.oliver@FreeBSD.org> X-Mailer: Sylpheed version 0.9.99-gtk2-20041024 (GTK+ 2.4.14; i386-portbld-freebsd5.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: x11@freebsd.org Subject: Re: ports/75666: add Matrox MGA Driver to xorg-server X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2005 11:54:54 -0000 Please take this patch as it covers an extra patch which is needed: diff -ruN --exclude=CVS /usr/ports/x11-servers/xorg-server/Makefile xorg-server/Makefile --- /usr/ports/x11-servers/xorg-server/Makefile Sat Jan 8 12:02:58 2005 +++ xorg-server/Makefile Sun Jan 9 01:24:27 2005 @@ -137,6 +137,38 @@ PLIST_SUB+= AMD64_I386="@comment " .endif +.if ${ARCH} == i386 +.if !defined(WITH_MATROX_GXX_DRIVER) +SCRIPTS_ENV+= HaveMatroxHal=NO +PLIST_SUB+= MATROX="@comment " +pre-fetch:: + @${ECHO_MSG} "********************************************************" + @${ECHO_MSG} "Define WITH_MATROX_GXX_DRIVER to include Matrox's extra" + @${ECHO_MSG} "\"HALLIB\" binary driver" + @${ECHO_MSG} "********************************************************" +.else +NO_PACKAGE= "Matrox drivers may not be distributed" +RESTRICTED= "Matrox drivers may not be distributed." +EXTRA_PATCHES= ${FILESDIR}/extra-patch-matrox +SCRIPTS_ENV+= HaveMatroxHal=YES +MGA_DRIVER_VERSION= 4.1-1 +MASTER_SITES+= ftp://ftp.matrox.com/pub/mga/archive/linux/2004/:mga +DISTFILES+= mgadriver-${MGA_DRIVER_VERSION}-src.tar.gz:mga +#EXTRACT_ONLY+= mgadriver-${MGA_DRIVER_VERSION}-src.tar.gz +RESTRICTED_FILES= mgadriver-${MGA_DRIVER_VERSION}-src.tar.gz +PLIST_SUB+= MATROX="" +post-extract:: + ${CP} -r ${WRKDIR}/mgadriver-${MGA_DRIVER_VERSION}-src/${PORTVERSION}/mga \ + ${WRKSRC}/programs/Xserver/hw/xfree86/drivers/ +post-install:: + ${INSTALL_DATA} ${WRKDIR}/mgadriver-${MGA_DRIVER_VERSION}-src/${PORTVERSION}/mga/README_HALLIB \ + ${PREFIX}/lib/X11/doc/README.mga_HALLIB +.endif # !WITH_MATROX_GXX_DRIVER +.else +SCRIPTS_ENV+= HaveMatroxHal=NO +PLIST_SUB+= MATROX="@comment " +.endif + .if !defined(NO_SUID_XSERVER) || ${NO_SUID_XSERVER} == NO pre-everything:: @${ECHO_MSG} "By default, the X Server installs as a set-user-id root binary. When run by" diff -ruN --exclude=CVS /usr/ports/x11-servers/xorg-server/distinfo xorg-server/distinfo --- /usr/ports/x11-servers/xorg-server/distinfo Fri Dec 31 13:41:22 2004 +++ xorg-server/distinfo Fri Jan 7 21:21:36 2005 @@ -2,3 +2,5 @@ SIZE (xorg/X11R6.8.1-src1.tar.gz) = 30562401 MD5 (xorg/X11R6.8.1-src3.tar.gz) = 8578e566e909e7c40300f44b6f0e88d3 SIZE (xorg/X11R6.8.1-src3.tar.gz) = 10014808 +MD5 (xorg/mgadriver-4.1-1-src.tar.gz) = 5376fed39733b605191cf4dbb138a3ff +SIZE(xorg/mgadriver-4.1-1-src.tar.gz) = 1148470 diff -ruN --exclude=CVS /usr/ports/x11-servers/xorg-server/files/extra-patch-matrox xorg-server/files/extra-patch-matrox --- /usr/ports/x11-servers/xorg-server/files/extra-patch-matrox Thu Jan 1 01:00:00 1970 +++ xorg-server/files/extra-patch-matrox Sun Jan 9 01:16:31 2005 @@ -0,0 +1,17 @@ +--- programs/Xserver/hw/xfree86/drivers/mga/Imakefile.orig Sun Jan 9 01:14:42 2005 ++++ programs/Xserver/hw/xfree86/drivers/mga/Imakefile Sun Jan 9 01:14:48 2005 +@@ -6,6 +6,14 @@ + #define IHaveModules + #include + ++#undef NormalRelocatableTarget ++#define NormalRelocatableTarget(objname,objlist) @@\ ++AllTarget(objname.Osuf) @@\ ++ @@\ ++objname.Osuf: objlist $(EXTRALIBRARYDEPS) @@\ ++ RemoveFile($@) @@\ ++ $(MODLD) $(MODLDCOMBINEFLAGS) objlist -L../../i2c -li2c -o $@ ++ + #if BuildMatroxHal + #define IHaveSubdirs + SUBDIRS=hallib diff -ruN --exclude=CVS /usr/ports/x11-servers/xorg-server/pkg-plist xorg-server/pkg-plist --- /usr/ports/x11-servers/xorg-server/pkg-plist Sat Jan 8 12:02:58 2005 +++ xorg-server/pkg-plist Mon Jan 3 21:27:37 2005 @@ -63,6 +63,7 @@ lib/X11/doc/README.fonts lib/X11/doc/README.i740 lib/X11/doc/README.i810 +%%MATROX%%lib/X11/doc/README.mga_HALLIB lib/X11/doc/README.mouse lib/X11/doc/README.newport lib/X11/doc/README.r128 @@ -93,6 +94,7 @@ %%I386%%lib/modules/drivers/i740_drv.o %%I386%%lib/modules/drivers/i810_drv.o lib/modules/drivers/mga_drv.o +%%MATROX%%lib/modules/drivers/mga_hal_drv.o %%AMD64_I386%%lib/modules/drivers/neomagic_drv.o %%I386%%lib/modules/drivers/nsc_drv.o %%SPARC64_NA%%lib/modules/drivers/nv_drv.o diff -ruN --exclude=CVS /usr/ports/x11-servers/xorg-server/scripts/configure xorg-server/scripts/configure --- /usr/ports/x11-servers/xorg-server/scripts/configure Sat Jan 8 12:02:58 2005 +++ xorg-server/scripts/configure Mon Jan 3 21:27:37 2005 @@ -24,6 +24,8 @@ echo "#define UseInstalledPrograms YES" >> $LOCALDEF echo "#define StandardIncludes -I${PREFIX}/include" >> $LOCALDEF echo "#define BuildXFree86ConfigTools YES" >> $LOCALDEF +# Matrox driver support +echo "#define HaveMatroxHal $HaveMatroxHal" >> $LOCALDEF if [ X$WITH_DEBUG != X ]; then export CFLAGS="-g $CFLAGS" -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-x11@FreeBSD.ORG Sun Jan 9 12:00:42 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE31E16A4CE for ; Sun, 9 Jan 2005 12:00:42 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F29243D2D for ; Sun, 9 Jan 2005 12:00:42 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j09C0gxK076076 for ; Sun, 9 Jan 2005 12:00:42 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j09C0gIr076075; Sun, 9 Jan 2005 12:00:42 GMT (envelope-from gnats) Date: Sun, 9 Jan 2005 12:00:42 GMT Message-Id: <200501091200.j09C0gIr076075@freefall.freebsd.org> To: x11@FreeBSD.org From: Oliver Lehmann Subject: Re: ports/75666: add Matrox MGA Driver to xorg-server X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Oliver Lehmann List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2005 12:00:42 -0000 The following reply was made to PR ports/75666; it has been noted by GNATS. From: Oliver Lehmann To: freebsd-gnats-submit@FreeBSD.org Cc: x11@freebsd.org Subject: Re: ports/75666: add Matrox MGA Driver to xorg-server Date: Sun, 9 Jan 2005 12:55:01 +0100 Please take this patch as it covers an extra patch which is needed: diff -ruN --exclude=CVS /usr/ports/x11-servers/xorg-server/Makefile xorg-server/Makefile --- /usr/ports/x11-servers/xorg-server/Makefile Sat Jan 8 12:02:58 2005 +++ xorg-server/Makefile Sun Jan 9 01:24:27 2005 @@ -137,6 +137,38 @@ PLIST_SUB+= AMD64_I386="@comment " .endif +.if ${ARCH} == i386 +.if !defined(WITH_MATROX_GXX_DRIVER) +SCRIPTS_ENV+= HaveMatroxHal=NO +PLIST_SUB+= MATROX="@comment " +pre-fetch:: + @${ECHO_MSG} "********************************************************" + @${ECHO_MSG} "Define WITH_MATROX_GXX_DRIVER to include Matrox's extra" + @${ECHO_MSG} "\"HALLIB\" binary driver" + @${ECHO_MSG} "********************************************************" +.else +NO_PACKAGE= "Matrox drivers may not be distributed" +RESTRICTED= "Matrox drivers may not be distributed." +EXTRA_PATCHES= ${FILESDIR}/extra-patch-matrox +SCRIPTS_ENV+= HaveMatroxHal=YES +MGA_DRIVER_VERSION= 4.1-1 +MASTER_SITES+= ftp://ftp.matrox.com/pub/mga/archive/linux/2004/:mga +DISTFILES+= mgadriver-${MGA_DRIVER_VERSION}-src.tar.gz:mga +#EXTRACT_ONLY+= mgadriver-${MGA_DRIVER_VERSION}-src.tar.gz +RESTRICTED_FILES= mgadriver-${MGA_DRIVER_VERSION}-src.tar.gz +PLIST_SUB+= MATROX="" +post-extract:: + ${CP} -r ${WRKDIR}/mgadriver-${MGA_DRIVER_VERSION}-src/${PORTVERSION}/mga \ + ${WRKSRC}/programs/Xserver/hw/xfree86/drivers/ +post-install:: + ${INSTALL_DATA} ${WRKDIR}/mgadriver-${MGA_DRIVER_VERSION}-src/${PORTVERSION}/mga/README_HALLIB \ + ${PREFIX}/lib/X11/doc/README.mga_HALLIB +.endif # !WITH_MATROX_GXX_DRIVER +.else +SCRIPTS_ENV+= HaveMatroxHal=NO +PLIST_SUB+= MATROX="@comment " +.endif + .if !defined(NO_SUID_XSERVER) || ${NO_SUID_XSERVER} == NO pre-everything:: @${ECHO_MSG} "By default, the X Server installs as a set-user-id root binary. When run by" diff -ruN --exclude=CVS /usr/ports/x11-servers/xorg-server/distinfo xorg-server/distinfo --- /usr/ports/x11-servers/xorg-server/distinfo Fri Dec 31 13:41:22 2004 +++ xorg-server/distinfo Fri Jan 7 21:21:36 2005 @@ -2,3 +2,5 @@ SIZE (xorg/X11R6.8.1-src1.tar.gz) = 30562401 MD5 (xorg/X11R6.8.1-src3.tar.gz) = 8578e566e909e7c40300f44b6f0e88d3 SIZE (xorg/X11R6.8.1-src3.tar.gz) = 10014808 +MD5 (xorg/mgadriver-4.1-1-src.tar.gz) = 5376fed39733b605191cf4dbb138a3ff +SIZE(xorg/mgadriver-4.1-1-src.tar.gz) = 1148470 diff -ruN --exclude=CVS /usr/ports/x11-servers/xorg-server/files/extra-patch-matrox xorg-server/files/extra-patch-matrox --- /usr/ports/x11-servers/xorg-server/files/extra-patch-matrox Thu Jan 1 01:00:00 1970 +++ xorg-server/files/extra-patch-matrox Sun Jan 9 01:16:31 2005 @@ -0,0 +1,17 @@ +--- programs/Xserver/hw/xfree86/drivers/mga/Imakefile.orig Sun Jan 9 01:14:42 2005 ++++ programs/Xserver/hw/xfree86/drivers/mga/Imakefile Sun Jan 9 01:14:48 2005 +@@ -6,6 +6,14 @@ + #define IHaveModules + #include + ++#undef NormalRelocatableTarget ++#define NormalRelocatableTarget(objname,objlist) @@\ ++AllTarget(objname.Osuf) @@\ ++ @@\ ++objname.Osuf: objlist $(EXTRALIBRARYDEPS) @@\ ++ RemoveFile($@) @@\ ++ $(MODLD) $(MODLDCOMBINEFLAGS) objlist -L../../i2c -li2c -o $@ ++ + #if BuildMatroxHal + #define IHaveSubdirs + SUBDIRS=hallib diff -ruN --exclude=CVS /usr/ports/x11-servers/xorg-server/pkg-plist xorg-server/pkg-plist --- /usr/ports/x11-servers/xorg-server/pkg-plist Sat Jan 8 12:02:58 2005 +++ xorg-server/pkg-plist Mon Jan 3 21:27:37 2005 @@ -63,6 +63,7 @@ lib/X11/doc/README.fonts lib/X11/doc/README.i740 lib/X11/doc/README.i810 +%%MATROX%%lib/X11/doc/README.mga_HALLIB lib/X11/doc/README.mouse lib/X11/doc/README.newport lib/X11/doc/README.r128 @@ -93,6 +94,7 @@ %%I386%%lib/modules/drivers/i740_drv.o %%I386%%lib/modules/drivers/i810_drv.o lib/modules/drivers/mga_drv.o +%%MATROX%%lib/modules/drivers/mga_hal_drv.o %%AMD64_I386%%lib/modules/drivers/neomagic_drv.o %%I386%%lib/modules/drivers/nsc_drv.o %%SPARC64_NA%%lib/modules/drivers/nv_drv.o diff -ruN --exclude=CVS /usr/ports/x11-servers/xorg-server/scripts/configure xorg-server/scripts/configure --- /usr/ports/x11-servers/xorg-server/scripts/configure Sat Jan 8 12:02:58 2005 +++ xorg-server/scripts/configure Mon Jan 3 21:27:37 2005 @@ -24,6 +24,8 @@ echo "#define UseInstalledPrograms YES" >> $LOCALDEF echo "#define StandardIncludes -I${PREFIX}/include" >> $LOCALDEF echo "#define BuildXFree86ConfigTools YES" >> $LOCALDEF +# Matrox driver support +echo "#define HaveMatroxHal $HaveMatroxHal" >> $LOCALDEF if [ X$WITH_DEBUG != X ]; then export CFLAGS="-g $CFLAGS" -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-x11@FreeBSD.ORG Sun Jan 9 13:08:05 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6520816A4CE for ; Sun, 9 Jan 2005 13:08:05 +0000 (GMT) Received: from eclipse.rootxs.nl (eclipse.rootxs.nl [217.148.166.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CBA243D2F for ; Sun, 9 Jan 2005 13:08:04 +0000 (GMT) (envelope-from dennis@rootxs.nl) Received: from mail.rootxs.nl (localhost [127.0.0.1]) by eclipse.rootxs.nl (Postfix) with ESMTP id 1F0F0123E44 for ; Sun, 9 Jan 2005 14:08:03 +0100 (CET) Received: from 80.56.110.127 (SquirrelMail authenticated user dennis@rootxs.nl); by mail.rootxs.nl with HTTP; Sun, 9 Jan 2005 14:08:03 +0100 (CET) Message-ID: <50496.80.56.110.127.1105276083.squirrel@80.56.110.127> Date: Sun, 9 Jan 2005 14:08:03 +0100 (CET) From: dennis@rootxs.nl To: x11@FreeBSD.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: i810 X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2005 13:08:05 -0000 Hello, I found some postings about the "i810" driver which is the driver Xorg -configure suggested. X hangs and nothing happens. I found several postings about simular problems but found no answer. Can you please point me into the right direction? ------------------------------------------------------------------------ dmesg ------------------------------------------------------------------------ agp0: mem 0xfeb80000-0xfebfffff,0xe8000000-0xefffffff irq 16 at device 2.0 on pci0 agp0: detected 892k stolen memory agp0: aperture size is 128M ------------------------------------------------------------------------ ------------------------------------------------------------------------ pciconf -lv ------------------------------------------------------------------------ agp0@pci0:2:0: class=0x030000 card=0x01601028 chip=0x25628086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82845G/GL/GV/GE/PE Integrated Graphics Device' class = display subclass = VGA ------------------------------------------------------------------------ ------------------------------------------------------------------------ xorg.conf ------------------------------------------------------------------------ Section "ServerLayout" Identifier "X.org Configured" Screen 0 "Screen0" 0 0 InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard" EndSection Section "Files" RgbPath "/usr/X11R6/lib/X11/rgb" ModulePath "/usr/X11R6/lib/modules" FontPath "/usr/X11R6/lib/X11/fonts/misc/" FontPath "/usr/X11R6/lib/X11/fonts/TTF/" FontPath "/usr/X11R6/lib/X11/fonts/Speedo/" FontPath "/usr/X11R6/lib/X11/fonts/Type1/" FontPath "/usr/X11R6/lib/X11/fonts/CID/" FontPath "/usr/X11R6/lib/X11/fonts/75dpi/" FontPath "/usr/X11R6/lib/X11/fonts/100dpi/" EndSection Section "Module" Load "dbe" # Load "dri" Load "extmod" Load "glx" Load "record" Load "xtrap" Load "freetype" Load "speedo" Load "type1" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "keyboard" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" EndSection Section "Monitor" #DisplaySize 340 270 # mm Identifier "Monitor0" VendorName "BNQ" ModelName "BenQ FP767" ### Uncomment if you don't want to default to DDC: # HorizSync 31.0 - 83.0 # VertRefresh 56.0 - 0.0 Option "DPMS" EndSection Section "Device" ### Available Driver options are:- ### Values: : integer, : float, : "True"/"False", ### : "String", : " Hz/kHz/MHz" ### [arg]: arg optional #Option "NoAccel" # [] #Option "SWcursor" # [] #Option "ColorKey" # #Option "CacheLines" # #Option "Dac6Bit" # [] #Option "DRI" # [] #Option "NoDDC" # [] #Option "ShowCache" # [] #Option "XvMCSurfaces" # #Option "PageFlip" # [] Identifier "Card0" Driver "i810" VendorName "Intel Corp." BoardName "82845G/GL [Brookdale-G] Chipset Integrated Graphics Device" BusID "PCI:0:2:0" EndSection Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" DefaultDepth 16 SubSection "Display" Viewport 0 0 Depth 1 EndSubSection SubSection "Display" Viewport 0 0 Depth 4 EndSubSection SubSection "Display" Viewport 0 0 Depth 8 EndSubSection SubSection "Display" Viewport 0 0 Depth 15 EndSubSection SubSection "Display" Viewport 0 0 Depth 16 EndSubSection SubSection "Display" Viewport 0 0 Depth 24 EndSubSection EndSection ------------------------------------------------------------------------ ------------------------------------------------------------------------ Xorg.0.log ------------------------------------------------------------------------ Release Date: 18 December 2003 X Protocol Version 11, Revision 0, Release 6.7 Build Operating System: FreeBSD 5.3 i386 [ELF] Current Operating System: FreeBSD midgard.noneofyourbusiness.nl 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Fri Nov 5 04:19:18 UTC 2004 root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 Build Date: 16 October 2004 Before reporting problems, check http://wiki.X.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/Xorg.0.log", Time: Sun Jan 9 13:53:46 2005 (==) Using config file: "/usr/X11R6/lib/X11/xorg.conf" (==) ServerLayout "X.org Configured" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "Card0" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (==) Keyboard: CustomKeycode disabled (WW) `fonts.dir' not found (or not valid) in "/usr/X11R6/lib/X11/fonts/Speedo/". Entry deleted from font path. (Run 'mkfontdir' on "/usr/X11R6/lib/X11/fonts/Speedo/"). (WW) `fonts.dir' not found (or not valid) in "/usr/X11R6/lib/X11/fonts/CID/". Entry deleted from font path. (Run 'mkfontdir' on "/usr/X11R6/lib/X11/fonts/CID/"). (**) FontPath set to "/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/TTF/,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/100dpi/" (**) RgbPath set to "/usr/X11R6/lib/X11/rgb" (**) ModulePath set to "/usr/X11R6/lib/modules" (II) Module ABI versions: X.Org ANSI C Emulation: 0.2 X.Org Video Driver: 0.7 X.Org XInput driver : 0.4 X.Org Server Extension : 0.2 X.Org Font Renderer : 0.4 (II) Loader running on freebsd (II) LoadModule: "bitmap" (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor="X.Org Foundation" compiled for 6.7.0, module version = 1.0.0 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.4 (II) Loading font Bitmap (II) LoadModule: "pcidata" (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor="X.Org Foundation" compiled for 6.7.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 0.7 (--) Using syscons driver with X support (version 2.0) (--) using VT number 9 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x00000000, mode1Res1 = 0x80000000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,2560 card 1028,0160 rev 01 class 06,00,00 hdr 00 (II) PCI: 00:02:0: chip 8086,2562 card 1028,0160 rev 01 class 03,00,00 hdr 00 (II) PCI: 00:1d:0: chip 8086,24c2 card 1028,0160 rev 01 class 0c,03,00 hdr 80 (II) PCI: 00:1d:1: chip 8086,24c4 card 1028,0160 rev 01 class 0c,03,00 hdr 00 (II) PCI: 00:1d:2: chip 8086,24c7 card 1028,0160 rev 01 class 0c,03,00 hdr 00 (II) PCI: 00:1d:7: chip 8086,24cd card 1028,0160 rev 01 class 0c,03,20 hdr 00 (II) PCI: 00:1e:0: chip 8086,244e card 0000,0000 rev 81 class 06,04,00 hdr 01 (II) PCI: 00:1f:0: chip 8086,24c0 card 0000,0000 rev 01 class 06,01,00 hdr 80 (II) PCI: 00:1f:1: chip 8086,24cb card 1028,0160 rev 01 class 01,01,8a hdr 00 (II) PCI: 00:1f:3: chip 8086,24c3 card 1028,0160 rev 01 class 0c,05,00 hdr 00 (II) PCI: 00:1f:5: chip 8086,24c5 card 1028,0160 rev 01 class 04,01,00 hdr 00 (II) PCI: 01:09:0: chip 14e4,4401 card 1028,8127 rev 01 class 02,00,00 hdr 00 (II) PCI: End of PCI scan (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,1), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] (II) PCI-to-PCI bridge: (II) Bus 1: bridge is at (0:30:0), (0,1,1), BCTRL: 0x0002 (VGA_EN is cleared) (II) Bus 1 non-prefetchable memory range: [0] -1 0 0xfe900000 - 0xfeafffff (0x200000) MX[B] (II) PCI-to-ISA bridge: (II) Bus -1: bridge is at (0:31:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is set) (--) PCI:*(0:2:0) Intel Corp. 82845G/GL [Brookdale-G] Chipset Integrated Graphics Device rev 1, Mem @ 0xe8000000/27, 0xfeb80000/19 (II) Addressable bus resource ranges are [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] [1] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) OS-reported resource ranges: [0] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [6] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) PCI Memory resource overlap reduced 0xf0000000 from 0xffffffff to 0xefffffff (II) Active PCI resource ranges: [0] -1 0 0xfe9fe000 - 0xfe9fffff (0x2000) MX[B]E [1] -1 0 0xfeb7f900 - 0xfeb7f9ff (0x100) MX[B]E [2] -1 0 0xfeb7fa00 - 0xfeb7fbff (0x200) MX[B]E [3] -1 0 0xfeb7fc00 - 0xfeb7ffff (0x400) MX[B]E [4] -1 0 0xffa80800 - 0xffa80fff (0x800) MX[B]E [5] -1 0 0xf0000000 - 0xefffffff (0x0) MX[B]EO [6] -1 0 0xfeb80000 - 0xfebfffff (0x80000) MX[B](B) [7] -1 0 0xe8000000 - 0xefffffff (0x8000000) MX[B](B) [8] -1 0 0x0000edc0 - 0x0000edff (0x40) IX[B]E [9] -1 0 0x0000ee00 - 0x0000eeff (0x100) IX[B]E [10] -1 0 0x0000eda0 - 0x0000edbf (0x20) IX[B]E [11] -1 0 0x0000ffa0 - 0x0000ffbf (0x20) IX[B]E [12] -1 0 0x00000374 - 0x00000377 (0x4) IX[B]E [13] -1 0 0x00000170 - 0x0000017f (0x10) IX[B]E [14] -1 0 0x000003f4 - 0x000003f7 (0x4) IX[B]E [15] -1 0 0x000001f0 - 0x000001ff (0x10) IX[B]E [16] -1 0 0x0000ff40 - 0x0000ff7f (0x40) IX[B]E [17] -1 0 0x0000ff60 - 0x0000ff7f (0x20) IX[B]E [18] -1 0 0x0000ff80 - 0x0000ffff (0x80) IX[B]E (II) PCI I/O resource overlap reduced 0x0000ff40 from 0x0000ff7f to 0x0000ff5f (II) PCI I/O resource overlap reduced 0x0000ff80 from 0x0000ffff to 0x0000ff9f (II) Active PCI resource ranges after removing overlaps: [0] -1 0 0xfe9fe000 - 0xfe9fffff (0x2000) MX[B]E [1] -1 0 0xfeb7f900 - 0xfeb7f9ff (0x100) MX[B]E [2] -1 0 0xfeb7fa00 - 0xfeb7fbff (0x200) MX[B]E [3] -1 0 0xfeb7fc00 - 0xfeb7ffff (0x400) MX[B]E [4] -1 0 0xffa80800 - 0xffa80fff (0x800) MX[B]E [5] -1 0 0xf0000000 - 0xefffffff (0x0) MX[B]EO [6] -1 0 0xfeb80000 - 0xfebfffff (0x80000) MX[B](B) [7] -1 0 0xe8000000 - 0xefffffff (0x8000000) MX[B](B) [8] -1 0 0x0000edc0 - 0x0000edff (0x40) IX[B]E [9] -1 0 0x0000ee00 - 0x0000eeff (0x100) IX[B]E [10] -1 0 0x0000eda0 - 0x0000edbf (0x20) IX[B]E [11] -1 0 0x0000ffa0 - 0x0000ffbf (0x20) IX[B]E [12] -1 0 0x00000374 - 0x00000377 (0x4) IX[B]E [13] -1 0 0x00000170 - 0x0000017f (0x10) IX[B]E [14] -1 0 0x000003f4 - 0x000003f7 (0x4) IX[B]E [15] -1 0 0x000001f0 - 0x000001ff (0x10) IX[B]E [16] -1 0 0x0000ff40 - 0x0000ff5f (0x20) IX[B]E [17] -1 0 0x0000ff60 - 0x0000ff7f (0x20) IX[B]E [18] -1 0 0x0000ff80 - 0x0000ff9f (0x20) IX[B]E (II) OS-reported resource ranges after removing overlaps with PCI: [0] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [6] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) All system resource ranges: [0] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0 0xfe9fe000 - 0xfe9fffff (0x2000) MX[B]E [6] -1 0 0xfeb7f900 - 0xfeb7f9ff (0x100) MX[B]E [7] -1 0 0xfeb7fa00 - 0xfeb7fbff (0x200) MX[B]E [8] -1 0 0xfeb7fc00 - 0xfeb7ffff (0x400) MX[B]E [9] -1 0 0xffa80800 - 0xffa80fff (0x800) MX[B]E [10] -1 0 0xf0000000 - 0xefffffff (0x0) MX[B]EO [11] -1 0 0xfeb80000 - 0xfebfffff (0x80000) MX[B](B) [12] -1 0 0xe8000000 - 0xefffffff (0x8000000) MX[B](B) [13] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [14] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [15] -1 0 0x0000edc0 - 0x0000edff (0x40) IX[B]E [16] -1 0 0x0000ee00 - 0x0000eeff (0x100) IX[B]E [17] -1 0 0x0000eda0 - 0x0000edbf (0x20) IX[B]E [18] -1 0 0x0000ffa0 - 0x0000ffbf (0x20) IX[B]E [19] -1 0 0x00000374 - 0x00000377 (0x4) IX[B]E [20] -1 0 0x00000170 - 0x0000017f (0x10) IX[B]E [21] -1 0 0x000003f4 - 0x000003f7 (0x4) IX[B]E [22] -1 0 0x000001f0 - 0x000001ff (0x10) IX[B]E [23] -1 0 0x0000ff40 - 0x0000ff5f (0x20) IX[B]E [24] -1 0 0x0000ff60 - 0x0000ff7f (0x20) IX[B]E [25] -1 0 0x0000ff80 - 0x0000ff9f (0x20) IX[B]E (II) LoadModule: "dbe" (II) Loading /usr/X11R6/lib/modules/extensions/libdbe.a (II) Module dbe: vendor="X.Org Foundation" compiled for 6.7.0, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.2 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "extmod" (II) Loading /usr/X11R6/lib/modules/extensions/libextmod.a (II) Module extmod: vendor="X.Org Foundation" compiled for 6.7.0, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.2 (II) Loading extension SHAPE (II) Loading extension MIT-SUNDRY-NONSTANDARD (II) Loading extension BIG-REQUESTS (II) Loading extension SYNC (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XC-MISC (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-Misc (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension FontCache (II) Loading extension TOG-CUP (II) Loading extension Extended-Visual-Information (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "glx" (II) Loading /usr/X11R6/lib/modules/extensions/libglx.a (II) Module glx: vendor="X.Org Foundation" compiled for 6.7.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.2 (II) Loading sub module "GLcore" (II) LoadModule: "GLcore" (II) Loading /usr/X11R6/lib/modules/extensions/libGLcore.a (II) Module GLcore: vendor="X.Org Foundation" compiled for 6.7.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.2 (II) Loading extension GLX (II) LoadModule: "record" (II) Loading /usr/X11R6/lib/modules/extensions/librecord.a (II) Module record: vendor="X.Org Foundation" compiled for 6.7.0, module version = 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.2 (II) Loading extension RECORD (II) LoadModule: "xtrap" (II) Loading /usr/X11R6/lib/modules/extensions/libxtrap.a (II) Module xtrap: vendor="X.Org Foundation" compiled for 6.7.0, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.2 (II) Loading extension DEC-XTRAP (II) LoadModule: "freetype" (II) Loading /usr/X11R6/lib/modules/fonts/libfreetype.so (II) Module freetype: vendor="X.Org Foundation & the After X-TT Project" compiled for 6.7.0, module version = 2.1.0 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.4 (II) Loading font FreeType (II) LoadModule: "speedo" (II) Loading /usr/X11R6/lib/modules/fonts/libspeedo.a (II) Module speedo: vendor="X.Org Foundation" compiled for 6.7.0, module version = 1.0.1 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.4 (II) Loading font Speedo (II) LoadModule: "type1" (II) Loading /usr/X11R6/lib/modules/fonts/libtype1.a (II) Module type1: vendor="X.Org Foundation" compiled for 6.7.0, module version = 1.0.2 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.4 (II) Loading font Type1 (II) Loading font CID (II) LoadModule: "i810" (II) Loading /usr/X11R6/lib/modules/drivers/i810_drv.o (II) Module i810: vendor="X.Org Foundation" compiled for 6.7.0, module version = 1.3.0 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 0.7 (II) LoadModule: "mouse" (II) Loading /usr/X11R6/lib/modules/input/mouse_drv.o (II) Module mouse: vendor="X.Org Foundation" compiled for 6.7.0, module version = 1.0.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 0.4 (II) I810: Driver for Intel Integrated Graphics Chipsets: i810, i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G (II) Primary Device is: PCI 00:02:0 (--) Chipset 845G found (II) resource ranges after xf86ClaimFixedResources() call: [0] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0 0xfe9fe000 - 0xfe9fffff (0x2000) MX[B]E [6] -1 0 0xfeb7f900 - 0xfeb7f9ff (0x100) MX[B]E [7] -1 0 0xfeb7fa00 - 0xfeb7fbff (0x200) MX[B]E [8] -1 0 0xfeb7fc00 - 0xfeb7ffff (0x400) MX[B]E [9] -1 0 0xffa80800 - 0xffa80fff (0x800) MX[B]E [10] -1 0 0xf0000000 - 0xefffffff (0x0) MX[B]EO [11] -1 0 0xfeb80000 - 0xfebfffff (0x80000) MX[B](B) [12] -1 0 0xe8000000 - 0xefffffff (0x8000000) MX[B](B) [13] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [14] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [15] -1 0 0x0000edc0 - 0x0000edff (0x40) IX[B]E [16] -1 0 0x0000ee00 - 0x0000eeff (0x100) IX[B]E [17] -1 0 0x0000eda0 - 0x0000edbf (0x20) IX[B]E [18] -1 0 0x0000ffa0 - 0x0000ffbf (0x20) IX[B]E [19] -1 0 0x00000374 - 0x00000377 (0x4) IX[B]E [20] -1 0 0x00000170 - 0x0000017f (0x10) IX[B]E [21] -1 0 0x000003f4 - 0x000003f7 (0x4) IX[B]E [22] -1 0 0x000001f0 - 0x000001ff (0x10) IX[B]E [23] -1 0 0x0000ff40 - 0x0000ff5f (0x20) IX[B]E [24] -1 0 0x0000ff60 - 0x0000ff7f (0x20) IX[B]E [25] -1 0 0x0000ff80 - 0x0000ff9f (0x20) IX[B]E (II) resource ranges after probing: [0] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0 0xfe9fe000 - 0xfe9fffff (0x2000) MX[B]E [6] -1 0 0xfeb7f900 - 0xfeb7f9ff (0x100) MX[B]E [7] -1 0 0xfeb7fa00 - 0xfeb7fbff (0x200) MX[B]E [8] -1 0 0xfeb7fc00 - 0xfeb7ffff (0x400) MX[B]E [9] -1 0 0xffa80800 - 0xffa80fff (0x800) MX[B]E [10] -1 0 0xf0000000 - 0xefffffff (0x0) MX[B]EO [11] -1 0 0xfeb80000 - 0xfebfffff (0x80000) MX[B](B) [12] -1 0 0xe8000000 - 0xefffffff (0x8000000) MX[B](B) [13] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] [14] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] [15] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] [16] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [17] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [18] -1 0 0x0000edc0 - 0x0000edff (0x40) IX[B]E [19] -1 0 0x0000ee00 - 0x0000eeff (0x100) IX[B]E [20] -1 0 0x0000eda0 - 0x0000edbf (0x20) IX[B]E [21] -1 0 0x0000ffa0 - 0x0000ffbf (0x20) IX[B]E [22] -1 0 0x00000374 - 0x00000377 (0x4) IX[B]E [23] -1 0 0x00000170 - 0x0000017f (0x10) IX[B]E [24] -1 0 0x000003f4 - 0x000003f7 (0x4) IX[B]E [25] -1 0 0x000001f0 - 0x000001ff (0x10) IX[B]E [26] -1 0 0x0000ff40 - 0x0000ff5f (0x20) IX[B]E [27] -1 0 0x0000ff60 - 0x0000ff7f (0x20) IX[B]E [28] -1 0 0x0000ff80 - 0x0000ff9f (0x20) IX[B]E [29] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] [30] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] (II) Setting vga for screen 0. (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Loading /usr/X11R6/lib/modules/libint10.a (II) Module int10: vendor="X.Org Foundation" compiled for 6.7.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 0.7 (II) Loading sub module "vbe" (II) LoadModule: "vbe" (II) Loading /usr/X11R6/lib/modules/libvbe.a (II) Module vbe: vendor="X.Org Foundation" compiled for 6.7.0, module version = 1.1.0 ABI class: X.Org Video Driver, version 0.7 (II) Loading sub module "vgahw" (II) LoadModule: "vgahw" (II) Loading /usr/X11R6/lib/modules/libvgahw.a (II) Module vgahw: vendor="X.Org Foundation" compiled for 6.7.0, module version = 0.1.0 ABI class: X.Org Video Driver, version 0.7 (**) I810(0): Depth 16, (--) framebuffer bpp 16 (==) I810(0): RGB weight 565 (==) I810(0): Default visual is TrueColor (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Reloading /usr/X11R6/lib/modules/libint10.a (II) I810(0): initializing int10 (==) I810(0): Write-combining range (0xa0000,0x20000) was already clear (==) I810(0): Write-combining range (0xc0000,0x40000) was already clear (II) I810(0): Primary V_BIOS segment is: 0xc000 (==) I810(0): Write-combining range (0x0,0x1000) was already clear (II) I810(0): VESA BIOS detected (II) I810(0): VESA VBE Version 3.0 (II) I810(0): VESA VBE Total Mem: 832 kB (II) I810(0): VESA VBE OEM: Intel(r)845G/845GL/845GE/845GV Graphics Chip Accelerated VGA BIOS (II) I810(0): VESA VBE OEM Software Rev: 1.0 (II) I810(0): VESA VBE OEM Vendor: Intel Corporation (II) I810(0): VESA VBE OEM Product: Intel(r)845G/845GL/845GE/845GV Graphics Controller (II) I810(0): VESA VBE OEM Product Rev: Hardware Version 0.0 (II) I810(0): Integrated Graphics Chipset: Intel(R) 845G (--) I810(0): Chipset: "845G" (--) I810(0): Linear framebuffer at 0xE8000000 (--) I810(0): IO registers at addr 0xFEB80000 (==) I810(0): Write-combining range (0xfeb80000,0x80000) was already clear (II) I810(0): detected 892 kB stolen memory. (II) I810(0): I830CheckAvailableMemory: 450560 kB available (II) I810(0): Will attempt to tell the BIOS that there is 12288 kB VideoRAM (==) I810(0): Write-combining range (0x0,0x1000) was already clear (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Reloading /usr/X11R6/lib/modules/libint10.a (II) I810(0): initializing int10 (==) I810(0): Write-combining range (0xa0000,0x20000) was already clear (II) I810(0): Primary V_BIOS segment is: 0xc000 (==) I810(0): Write-combining range (0x0,0x1000) was already clear (II) I810(0): VESA BIOS detected (II) I810(0): VESA VBE Version 3.0 (II) I810(0): VESA VBE Total Mem: 12288 kB (II) I810(0): VESA VBE OEM: Intel(r)845G/845GL/845GE/845GV Graphics Chip Accelerated VGA BIOS (II) I810(0): VESA VBE OEM Software Rev: 1.0 (II) I810(0): VESA VBE OEM Vendor: Intel Corporation (II) I810(0): VESA VBE OEM Product: Intel(r)845G/845GL/845GE/845GV Graphics Controller (II) I810(0): VESA VBE OEM Product Rev: Hardware Version 0.0 (II) I810(0): BIOS now sees 12288 kB VideoRAM (--) I810(0): Pre-allocated VideoRAM: 892 kByte (==) I810(0): VideoRAM: 32768 kByte (==) I810(0): video overlay key set to 0x83e (**) I810(0): page flipping disabled (--) I810(0): Maximum frambuffer space: 32616 kByte (==) I810(0): Using gamma correction (1.0, 1.0, 1.0) (II) I810(0): 1 display pipe available. (==) I810(0): Display Info: enabled. (II) I810(0): Broken BIOSes cause the system to hang here. If you encounter this problem please add Option "DisplayInfo" "FALSE" to the Device section of your XF86Config file. (II) I810(0): Display Info: CRT: attached: FALSE, present: FALSE, size: (0,0) (II) I810(0): Display Info: TV: attached: FALSE, present: FALSE, size: (0,0) (II) I810(0): Display Info: DFP (digital flat panel): attached: FALSE, present: FALSE, size: (0,0) (II) I810(0): Display Info: LFP (local flat panel): attached: FALSE, present: FALSE, size: (0,0) (II) I810(0): Display Info: TV2 (second TV): attached: FALSE, present: FALSE, size: (0,0) (II) I810(0): Display Info: DFP2 (second digital flat panel): attached: FALSE, present: FALSE, size: (0,0) (II) I810(0): Currently active displays on Pipe A: (II) I810(0): CRT (II) Loading sub module "ddc" (II) LoadModule: "ddc" (II) Loading /usr/X11R6/lib/modules/libddc.a (II) Module ddc: vendor="X.Org Foundation" compiled for 6.7.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 0.7 (II) I810(0): VESA VBE DDC supported (II) I810(0): VESA VBE DDC Level 2 (II) I810(0): VESA VBE DDC transfer in appr. 1 sec. (II) I810(0): VESA VBE DDC read successfully (II) I810(0): Manufacturer: BNQ Model: 765b Serial#: 6186 (II) I810(0): Year: 2004 Week: 17 (II) I810(0): EDID Version: 1.3 (II) I810(0): Analog Display Input, Input Voltage Level: 0.700/0.700 V (II) I810(0): Sync: Separate Composite (II) I810(0): Max H-Image Size [cm]: horiz.: 34 vert.: 27 (II) I810(0): Gamma: 2.20 (II) I810(0): DPMS capabilities: StandBy Suspend Off; RGB/Color Display (II) I810(0): First detailed timing is preferred mode (II) I810(0): redX: 0.640 redY: 0.340 greenX: 0.290 greenY: 0.609 (II) I810(0): blueX: 0.140 blueY: 0.069 whiteX: 0.310 whiteY: 0.330 (II) I810(0): Supported VESA Video Modes: (II) I810(0): 720x400@70Hz (II) I810(0): 640x480@60Hz (II) I810(0): 640x480@67Hz (II) I810(0): 640x480@72Hz (II) I810(0): 640x480@75Hz (II) I810(0): 800x600@60Hz (II) I810(0): 800x600@72Hz (II) I810(0): 800x600@75Hz (II) I810(0): 832x624@75Hz (II) I810(0): 1024x768@60Hz (II) I810(0): 1024x768@70Hz (II) I810(0): 1024x768@75Hz (II) I810(0): 1280x1024@75Hz (II) I810(0): 1152x870@75Hz (II) I810(0): Manufacturer's mask: 0 (II) I810(0): Supported Future Video Modes: (II) I810(0): #0: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) I810(0): #1: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) I810(0): #2: hsize: 1280 vsize 1024 refresh: 72 vid: 35969 (II) I810(0): Supported additional Video Mode: (II) I810(0): clock: 108.0 MHz Image Size: 338 x 270 mm (II) I810(0): h_active: 1280 h_sync: 1328 h_sync_end 1440 h_blank_end 1688 h_border: 0 (II) I810(0): v_active: 1024 v_sync: 1025 v_sync_end 1028 v_blanking: 1066 v_border: 0 (II) I810(0): Supported additional Video Mode: (II) I810(0): clock: 25.2 MHz Image Size: 338 x 270 mm (II) I810(0): h_active: 640 h_sync: 656 h_sync_end 752 h_blank_end 800 h_border: 0 (II) I810(0): v_active: 350 v_sync: 387 v_sync_end 389 v_blanking: 449 v_border: 0 (II) I810(0): Ranges: V min: 56 V max: 76 Hz, H min: 31 H max: 83 kHz, PixClock max 140 MHz (II) I810(0): Monitor name: BenQ FP767 (II) I810(0): Will use BIOS call 0x5f05 to set refresh rates for CRTs. (II) I810(0): Will use BIOS call 0x5f64 to enable displays. (--) I810(0): Maximum space available for video modes: 12288 kByte Mode: 20 (132x25) ModeAttributes: 0xf WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005d0f BytesPerScanline: 16847 XResolution: 132 YResolution: 25 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 4 NumberOfBanks: 1 MemoryModel: 0 BankSize: 0 NumberOfImages: 0 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0x0 LinBytesPerScanLine: 0 BnkNumberOfImagePages: 0 LinNumberOfImagePages: 0 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 0 Mode: 21 (132x43) ModeAttributes: 0xf WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005d0f BytesPerScanline: 16849 XResolution: 132 YResolution: 43 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 4 NumberOfBanks: 1 MemoryModel: 0 BankSize: 0 NumberOfImages: 0 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0x0 LinBytesPerScanLine: 0 BnkNumberOfImagePages: 0 LinNumberOfImagePages: 0 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 0 Mode: 22 (132x50) ModeAttributes: 0xf WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005d0f BytesPerScanline: 16847 XResolution: 132 YResolution: 50 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 4 NumberOfBanks: 1 MemoryModel: 0 BankSize: 0 NumberOfImages: 0 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0x0 LinBytesPerScanLine: 0 BnkNumberOfImagePages: 0 LinNumberOfImagePages: 0 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 0 Mode: 23 (132x60) ModeAttributes: 0xf WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005d0f BytesPerScanline: 16847 XResolution: 132 YResolution: 60 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 4 NumberOfBanks: 1 MemoryModel: 0 BankSize: 0 NumberOfImages: 0 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0x0 LinBytesPerScanLine: 0 BnkNumberOfImagePages: 0 LinNumberOfImagePages: 0 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 0 Mode: 30 (640x480) ModeAttributes: 0x9b WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005d0f BytesPerScanline: 640 XResolution: 640 YResolution: 480 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 37 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 640 BnkNumberOfImagePages: 37 LinNumberOfImagePages: 37 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 Mode: 32 (800x600) ModeAttributes: 0x9b WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005d0f BytesPerScanline: 800 XResolution: 800 YResolution: 600 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 26 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 800 BnkNumberOfImagePages: 26 LinNumberOfImagePages: 26 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 Mode: 34 (1024x768) ModeAttributes: 0x9b WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005d0f BytesPerScanline: 1024 XResolution: 1024 YResolution: 768 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 15 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 1024 BnkNumberOfImagePages: 15 LinNumberOfImagePages: 15 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 Mode: 38 (1280x1024) ModeAttributes: 0x9b WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005d0f BytesPerScanline: 1280 XResolution: 1280 YResolution: 1024 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 8 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 1280 BnkNumberOfImagePages: 8 LinNumberOfImagePages: 8 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 Mode: 3a (1600x1200) ModeAttributes: 0x9b WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005d0f BytesPerScanline: 1600 XResolution: 1600 YResolution: 1200 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 5 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 1600 BnkNumberOfImagePages: 5 LinNumberOfImagePages: 5 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 Mode: 3c (1920x1440) ModeAttributes: 0x9a WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005d0f BytesPerScanline: 1920 XResolution: 1920 YResolution: 1440 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 3 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 1920 BnkNumberOfImagePages: 3 LinNumberOfImagePages: 3 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 *Mode: 41 (640x480) ModeAttributes: 0x9b WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005d0f BytesPerScanline: 1280 XResolution: 640 YResolution: 480 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 20 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 1280 BnkNumberOfImagePages: 20 LinNumberOfImagePages: 20 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 *Mode: 43 (800x600) ModeAttributes: 0x9b WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005d0f BytesPerScanline: 1600 XResolution: 800 YResolution: 600 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 11 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 1600 BnkNumberOfImagePages: 11 LinNumberOfImagePages: 11 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 *Mode: 45 (1024x768) ModeAttributes: 0x9b WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005d0f BytesPerScanline: 2048 XResolution: 1024 YResolution: 768 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 7 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 2048 BnkNumberOfImagePages: 7 LinNumberOfImagePages: 7 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 *Mode: 49 (1280x1024) ModeAttributes: 0x9b WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005d0f BytesPerScanline: 2560 XResolution: 1280 YResolution: 1024 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 3 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 2560 BnkNumberOfImagePages: 3 LinNumberOfImagePages: 3 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 *(WW) (1600x1200,Monitor0) mode clock 162MHz exceeds DDC maximum 140MHz Mode: 4b (1600x1200) ModeAttributes: 0x9b WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005d0f BytesPerScanline: 3200 XResolution: 1600 YResolution: 1200 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 2 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 3200 BnkNumberOfImagePages: 2 LinNumberOfImagePages: 2 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 Mode: 4d (1920x1440) ModeAttributes: 0x9a WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005d0f BytesPerScanline: 3840 XResolution: 1920 YResolution: 1440 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 1 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 3840 BnkNumberOfImagePages: 1 LinNumberOfImagePages: 1 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 Mode: 50 (640x480) ModeAttributes: 0x9b WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005d0f BytesPerScanline: 2560 XResolution: 640 YResolution: 480 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 9 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 8 RsvdFieldPosition: 24 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 2560 BnkNumberOfImagePages: 9 LinNumberOfImagePages: 9 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 8 LinRsvdFieldPosition: 24 MaxPixelClock: 230000000 Mode: 52 (800x600) ModeAttributes: 0x9b WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005d0f BytesPerScanline: 3200 XResolution: 800 YResolution: 600 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 5 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 8 RsvdFieldPosition: 24 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 3200 BnkNumberOfImagePages: 5 LinNumberOfImagePages: 5 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 8 LinRsvdFieldPosition: 24 MaxPixelClock: 230000000 Mode: 54 (1024x768) ModeAttributes: 0x9b WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005d0f BytesPerScanline: 4096 XResolution: 1024 YResolution: 768 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 3 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 8 RsvdFieldPosition: 24 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 4096 BnkNumberOfImagePages: 3 LinNumberOfImagePages: 3 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 8 LinRsvdFieldPosition: 24 MaxPixelClock: 230000000 Mode: 58 (1280x1024) ModeAttributes: 0x9b WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005d0f BytesPerScanline: 5120 XResolution: 1280 YResolution: 1024 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 1 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 8 RsvdFieldPosition: 24 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 5120 BnkNumberOfImagePages: 1 LinNumberOfImagePages: 1 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 8 LinRsvdFieldPosition: 24 MaxPixelClock: 230000000 Mode: 5a (1600x1200) ModeAttributes: 0x9b WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005d0f BytesPerScanline: 6400 XResolution: 1600 YResolution: 1200 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 0 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 8 RsvdFieldPosition: 24 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 6400 BnkNumberOfImagePages: 0 LinNumberOfImagePages: 0 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 8 LinRsvdFieldPosition: 24 MaxPixelClock: 230000000 Mode: 5c (1920x1440) ModeAttributes: 0x9a WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005d0f BytesPerScanline: 7680 XResolution: 1920 YResolution: 1440 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 0 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 8 RsvdFieldPosition: 24 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 7680 BnkNumberOfImagePages: 0 LinNumberOfImagePages: 0 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 8 LinRsvdFieldPosition: 24 MaxPixelClock: 230000000 (II) I810(0): Monitor0: Using default hsync range of 31.00-83.00 kHz (II) I810(0): Monitor0: Using default vrefresh range of 56.00-76.00 Hz (II) I810(0): Increasing the scanline pitch to allow tiling mode (1600 -> 2048). (--) I810(0): Virtual size is 1600x1200 (pitch 2048) (**) I810(0): *Built-in mode "1600x1200" (**) I810(0): *Built-in mode "1280x1024" (**) I810(0): *Built-in mode "1024x768" (**) I810(0): *Built-in mode "800x600" (**) I810(0): *Built-in mode "640x480" (WW) (1600x1200,Monitor0) mode clock 162MHz exceeds DDC maximum 140MHz (WW) (1600x1200,Monitor0) mode clock 175.5MHz exceeds DDC maximum 140MHz (WW) (1600x1200,Monitor0) mode clock 189MHz exceeds DDC maximum 140MHz (WW) (1600x1200,Monitor0) mode clock 202.5MHz exceeds DDC maximum 140MHz (WW) (1600x1200,Monitor0) mode clock 229.5MHz exceeds DDC maximum 140MHz (II) I810(0): Attempting to use 65Hz refresh for mode "1600x1200" (4b) (WW) (1280x1024,Monitor0) mode clock 157.5MHz exceeds DDC maximum 140MHz (II) I810(0): Attempting to use 75Hz refresh for mode "1280x1024" (49) (II) I810(0): Attempting to use 75Hz refresh for mode "1024x768" (45) (II) I810(0): Attempting to use 72Hz refresh for mode "800x600" (43) (II) I810(0): Attempting to use 73Hz refresh for mode "640x480" (41) (--) I810(0): Display dimensions: (340, 270) mm (--) I810(0): DPI set to (119, 112) (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/X11R6/lib/modules/libfb.a (II) Module fb: vendor="X.Org Foundation" compiled for 6.7.0, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.2 (II) Loading sub module "xaa" (II) LoadModule: "xaa" (II) Loading /usr/X11R6/lib/modules/libxaa.a (II) Module xaa: vendor="X.Org Foundation" compiled for 6.7.0, module version = 1.1.0 ABI class: X.Org Video Driver, version 0.7 (II) Loading sub module "ramdac" (II) LoadModule: "ramdac" (II) Loading /usr/X11R6/lib/modules/libramdac.a (II) Module ramdac: vendor="X.Org Foundation" compiled for 6.7.0, module version = 0.1.0 ABI class: X.Org Video Driver, version 0.7 (==) I810(0): Write-combining range (0x0,0x1000) was already clear (==) I810(0): VBE Restore workaround: enabled. (II) Loading sub module "shadow" (II) LoadModule: "shadow" (II) Loading /usr/X11R6/lib/modules/libshadow.a (II) Module shadow: vendor="X.Org Foundation" compiled for 6.7.0, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.2 (II) do I need RAC? No, I don't. (II) resource ranges after preInit: [0] 0 0 0xfeb80000 - 0xfebfffff (0x80000) MS[B] [1] 0 0 0xe8000000 - 0xefffffff (0x8000000) MS[B] [2] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [3] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [4] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [5] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [6] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [7] -1 0 0xfe9fe000 - 0xfe9fffff (0x2000) MX[B]E [8] -1 0 0xfeb7f900 - 0xfeb7f9ff (0x100) MX[B]E [9] -1 0 0xfeb7fa00 - 0xfeb7fbff (0x200) MX[B]E [10] -1 0 0xfeb7fc00 - 0xfeb7ffff (0x400) MX[B]E [11] -1 0 0xffa80800 - 0xffa80fff (0x800) MX[B]E [12] -1 0 0xf0000000 - 0xefffffff (0x0) MX[B]EO [13] -1 0 0xfeb80000 - 0xfebfffff (0x80000) MX[B](B) [14] -1 0 0xe8000000 - 0xefffffff (0x8000000) MX[B](B) [15] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B](OprD) [16] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B](OprD) [17] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B](OprD) [18] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [19] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [20] -1 0 0x0000edc0 - 0x0000edff (0x40) IX[B]E [21] -1 0 0x0000ee00 - 0x0000eeff (0x100) IX[B]E [22] -1 0 0x0000eda0 - 0x0000edbf (0x20) IX[B]E [23] -1 0 0x0000ffa0 - 0x0000ffbf (0x20) IX[B]E [24] -1 0 0x00000374 - 0x00000377 (0x4) IX[B]E [25] -1 0 0x00000170 - 0x0000017f (0x10) IX[B]E [26] -1 0 0x000003f4 - 0x000003f7 (0x4) IX[B]E [27] -1 0 0x000001f0 - 0x000001ff (0x10) IX[B]E [28] -1 0 0x0000ff40 - 0x0000ff5f (0x20) IX[B]E [29] -1 0 0x0000ff60 - 0x0000ff7f (0x20) IX[B]E [30] -1 0 0x0000ff80 - 0x0000ff9f (0x20) IX[B]E [31] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B](OprU) [32] 0 0 0x000003c0 - 0x000003df (0x20) IS[B](OprU) (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Reloading /usr/X11R6/lib/modules/libint10.a (II) I810(0): initializing int10 (==) I810(0): Write-combining range (0xa0000,0x20000) was already clear (II) I810(0): Primary V_BIOS segment is: 0xc000 (==) I810(0): Write-combining range (0x0,0x1000) was already clear (II) I810(0): VESA BIOS detected (II) I810(0): VESA VBE Version 3.0 (II) I810(0): VESA VBE Total Mem: 832 kB (II) I810(0): VESA VBE OEM: Intel(r)845G/845GL/845GE/845GV Graphics Chip Accelerated VGA BIOS (II) I810(0): VESA VBE OEM Software Rev: 1.0 (II) I810(0): VESA VBE OEM Vendor: Intel Corporation (II) I810(0): VESA VBE OEM Product: Intel(r)845G/845GL/845GE/845GV Graphics Controller (II) I810(0): VESA VBE OEM Product Rev: Hardware Version 0.0 (==) I810(0): Default visual is TrueColor (II) I810(0): Allocated 128 kB for the ring buffer at 0x0 (II) I810(0): Allocating at least 384 scanlines for pixmap cache (II) I810(0): Initial framebuffer allocation size: 6336 kByte (II) I810(0): Allocated 4 kB for HW cursor at 0x7fff000 (II) I810(0): Allocated 4 kB for Overlay registers at 0x7ffe000 (0x09058000). (II) I810(0): Allocated 64 kB for the scratch buffer at 0x7fee000 (II) I810(0): Updated framebuffer allocation size from 6336 to 8192 kByte (II) I810(0): Updated pixmap cache from 384 scanlines to 848 scanlines (II) I810(0): 0x87188f4: Memory at offset 0x00020000, size 8192 kBytes (II) I810(0): 0x8718914: Memory at offset 0x07fff000, size 4 kBytes (II) I810(0): 0x8718938: Memory at offset 0x00000000, size 128 kBytes (II) I810(0): 0x8718968: Memory at offset 0x07fee000, size 64 kBytes (II) I810(0): 0x8718988: Memory at offset 0x07ffe000, size 4 kBytes (==) I810(0): Write-combining range (0xfeb80000,0x80000) was already clear (==) I810(0): Write-combining range (0xe8000000,0x8000000) (II) I810(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000 (==) I810(0): Write-combining range (0xa0000,0x10000) was already clear (II) I810(0): xf86BindGARTMemory: bind key 12 at 0x000df000 (pgoffset 223) (II) I810(0): xf86BindGARTMemory: bind key 9 at 0x07fff000 (pgoffset 32767) (II) I810(0): xf86BindGARTMemory: bind key 11 at 0x07fee000 (pgoffset 32750) (II) I810(0): xf86BindGARTMemory: bind key 10 at 0x07ffe000 (pgoffset 32766) (WW) I810(0): PGTBL_ER is 0x00000049 (WW) I810(0): Extended BIOS function 0x5f05 not supported. (II) I810(0): BIOS call 0x5f05 not supported, setting refresh with VBE 3 method. (II) I810(0): Not using BIOS call 0x5f64 to enable displays. (II) I810(0): Display plane A is enabled. (II) I810(0): Display plane B is disabled. (II) I810(0): PIPEACONF is 0x80000000 (II) I810(0): Mode bandwidth is 115 Mpixel/s (WW) I810(0): Extended BIOS function 0x5f28 not supported. (WW) I810(0): Extended BIOS function 0x5f61 not supported. (II) I810(0): Using XFree86 Acceleration Architecture (XAA) Screen to screen bit blits Solid filled rectangles 8x8 mono pattern filled rectangles Indirect CPU to Screen color expansion Solid Horizontal and Vertical Lines Offscreen Pixmaps Setting up tile and stipple cache: 32 128x128 slots 22 256x256 slots (==) I810(0): Backing store disabled (==) I810(0): Silken mouse enabled (II) I810(0): Initializing HW Cursor (**) Option "dpms" (**) I810(0): DPMS enabled (WW) I810(0): Disabling XVideo output because the mode pixel rate (125 MHz) exceeds the hardware limit (120 MHz) (II) I810(0): direct rendering: Failed (==) RandR enabled (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 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 (**) Option "Protocol" "auto" (**) Mouse0: Device: "/dev/sysmouse" (**) Mouse0: Protocol: "auto" (**) Option "CorePointer" (**) Mouse0: Core Pointer (**) Option "Device" "/dev/sysmouse" (==) Mouse0: Emulate3Buttons, Emulate3Timeout: 50 (==) Mouse0: Buttons: 3 (II) Keyboard "Keyboard0" handled by legacy driver (II) XINPUT: Adding extended input device "Mouse0" (type: MOUSE) (II) Mouse0: SetupAuto: hw.iftype is 4, hw.model is 0 (II) Mouse0: SetupAuto: protocol is SysMouse (WW) I810(0): Setting the original video mode instead of restoring the saved state (II) I810(0): xf86UnbindGARTMemory: unbind key 12 (II) I810(0): xf86UnbindGARTMemory: unbind key 9 (II) I810(0): xf86UnbindGARTMemory: unbind key 11 (II) I810(0): xf86UnbindGARTMemory: unbind key 10 ------------------------------------------------------------------------ Kind regards, Dennis Cabooter http://www.rootxs.nl "We could change the world if god would give us the source-code" From owner-freebsd-x11@FreeBSD.ORG Sun Jan 9 15:40:24 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5433F16A4CE; Sun, 9 Jan 2005 15:40:24 +0000 (GMT) Received: from niobe.ijs.si (mail.ijs.si [193.2.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B64843D2D; Sun, 9 Jan 2005 15:40:23 +0000 (GMT) (envelope-from dejan.lesjak@ijs.si) Received: from localhost (localhost.ijs.si [127.0.0.1]) by niobe.ijs.si (Postfix) with ESMTP id 2B6E11DD5A8; Sun, 9 Jan 2005 16:40:22 +0100 (CET) Received: from niobe.ijs.si ([127.0.0.1]) by localhost (niobe.ijs.si [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29245-09; Sun, 9 Jan 2005 16:40:11 +0100 (CET) Received: from metatron.ijs.si (metatron.ijs.si [193.2.4.152]) by niobe.ijs.si (Postfix) with ESMTP id 12E111DD606; Sun, 9 Jan 2005 16:40:11 +0100 (CET) Received: from idefix.ijs.si (idefix.ijs.si [193.2.4.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by metatron.ijs.si (Postfix) with ESMTP id E11A31C00B02; Sun, 9 Jan 2005 16:40:10 +0100 (CET) From: Dejan Lesjak To: freebsd-x11@freebsd.org Date: Sun, 9 Jan 2005 16:40:09 +0100 User-Agent: KMail/1.7.2 References: <50496.80.56.110.127.1105276083.squirrel@80.56.110.127> In-Reply-To: <50496.80.56.110.127.1105276083.squirrel@80.56.110.127> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200501091640.10230.dejan.lesjak@ijs.si> X-Virus-Scanned: amavisd-new at ijs.si cc: x11@freebsd.org cc: dennis@rootxs.nl Subject: Re: i810 X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2005 15:40:24 -0000 On Sunday 09 of January 2005 14:08, dennis@rootxs.nl wrote: > Hello, > > I found some postings about the "i810" driver which is the driver Xorg > -configure suggested. X hangs and nothing happens. I found several > postings about simular problems but found no answer. Can you please point > me into the right direction? [snip] > Xorg.0.log > ------------------------------------------------------------------------ > Release Date: 18 December 2003 > X Protocol Version 11, Revision 0, Release 6.7 > Build Operating System: FreeBSD 5.3 i386 [ELF] > Current Operating System: FreeBSD midgard.noneofyourbusiness.nl > 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Fri Nov 5 04:19:18 UTC 2004 > root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 Build Date: > 16 October 2004 Try to upgrade to X.Org 6.8.1 which is available in ports and see if it works better. Dejan From owner-freebsd-x11@FreeBSD.ORG Sun Jan 9 15:40:24 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5433F16A4CE; Sun, 9 Jan 2005 15:40:24 +0000 (GMT) Received: from niobe.ijs.si (mail.ijs.si [193.2.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B64843D2D; Sun, 9 Jan 2005 15:40:23 +0000 (GMT) (envelope-from dejan.lesjak@ijs.si) Received: from localhost (localhost.ijs.si [127.0.0.1]) by niobe.ijs.si (Postfix) with ESMTP id 2B6E11DD5A8; Sun, 9 Jan 2005 16:40:22 +0100 (CET) Received: from niobe.ijs.si ([127.0.0.1]) by localhost (niobe.ijs.si [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29245-09; Sun, 9 Jan 2005 16:40:11 +0100 (CET) Received: from metatron.ijs.si (metatron.ijs.si [193.2.4.152]) by niobe.ijs.si (Postfix) with ESMTP id 12E111DD606; Sun, 9 Jan 2005 16:40:11 +0100 (CET) Received: from idefix.ijs.si (idefix.ijs.si [193.2.4.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by metatron.ijs.si (Postfix) with ESMTP id E11A31C00B02; Sun, 9 Jan 2005 16:40:10 +0100 (CET) From: Dejan Lesjak To: freebsd-x11@freebsd.org Date: Sun, 9 Jan 2005 16:40:09 +0100 User-Agent: KMail/1.7.2 References: <50496.80.56.110.127.1105276083.squirrel@80.56.110.127> In-Reply-To: <50496.80.56.110.127.1105276083.squirrel@80.56.110.127> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200501091640.10230.dejan.lesjak@ijs.si> X-Virus-Scanned: amavisd-new at ijs.si cc: x11@freebsd.org cc: dennis@rootxs.nl Subject: Re: i810 X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2005 15:40:24 -0000 On Sunday 09 of January 2005 14:08, dennis@rootxs.nl wrote: > Hello, > > I found some postings about the "i810" driver which is the driver Xorg > -configure suggested. X hangs and nothing happens. I found several > postings about simular problems but found no answer. Can you please point > me into the right direction? [snip] > Xorg.0.log > ------------------------------------------------------------------------ > Release Date: 18 December 2003 > X Protocol Version 11, Revision 0, Release 6.7 > Build Operating System: FreeBSD 5.3 i386 [ELF] > Current Operating System: FreeBSD midgard.noneofyourbusiness.nl > 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Fri Nov 5 04:19:18 UTC 2004 > root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 Build Date: > 16 October 2004 Try to upgrade to X.Org 6.8.1 which is available in ports and see if it works better. Dejan From owner-freebsd-x11@FreeBSD.ORG Sun Jan 9 17:35:01 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07E7116A4CE; Sun, 9 Jan 2005 17:35:01 +0000 (GMT) Received: from 212.106.238.57.adsl.jazztel.es (212.106.238.57.adsl.jazztel.es [212.106.238.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9143B43D48; Sun, 9 Jan 2005 17:34:59 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from [192.168.254.16] (orion.redesjm.local [192.168.254.16]) j09HYqtq000750; Sun, 9 Jan 2005 18:34:55 +0100 (CET) (envelope-from freebsd@redesjm.local) Message-ID: <41E16B3C.30302@redesjm.local> Date: Sun, 09 Jan 2005 18:34:52 +0100 From: Jose M Rodriguez User-Agent: Mozilla Thunderbird 1.0 (X11/20050106) X-Accept-Language: es-es, es MIME-Version: 1.0 To: Brooks Davis References: <41DDC4F2.5090709@yahoo.com> <20050107003806.GA14003@odin.ac.hmc.edu> <41DE5242.4030606@redesjm.local> <20050107182024.GB30931@odin.ac.hmc.edu> In-Reply-To: <20050107182024.GB30931@odin.ac.hmc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.29.0.5; VDF: 6.29.0.31; host: antares.redesjm.local) cc: Rob cc: freebsd-current cc: x11@freebsd.org Subject: Re: Xorg ICE vs. Xfce4 (4.2-RC3) needs fixing /etc/rc.d/cleartmp X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2005 17:35:01 -0000 Brooks Davis escribió: >On Fri, Jan 07, 2005 at 10:11:30AM +0100, Jose M Rodriguez wrote: > > >>Brooks Davis escribió: >> >> >> >>>Could you please try the following patch? It does the same thing, but >>>gives the inode paranoid a way to disable the creation of these >>>directories or only create the ones they need. >>> >>>-- Brooks >>> >>>Index: rc.d/cleartmp >>>=================================================================== >>>RCS file: /usr/cvs/src/etc/rc.d/cleartmp,v >>>retrieving revision 1.11 >>>diff -u -p -r1.11 cleartmp >>>--- rc.d/cleartmp 7 Oct 2004 13:55:25 -0000 1.11 >>>+++ rc.d/cleartmp 7 Jan 2005 00:31:51 -0000 >>>@@ -35,5 +35,7 @@ run_rc_command "$1" >>># restarting X >>># >>>rm -f /tmp/.X[0-9]-lock >>>-rm -fr /tmp/.X11-unix >>>-mkdir -m 1777 /tmp/.X11-unix >>>+if [ -n ${clear_tmp_xdirs} ]; then >>>+ rm -fr ${clear_tmp_xdirs} >>>+ mkdir -m 1777 ${clear_tmp_xdirs} >>>+fi >>>Index: defaults/rc.conf >>>=================================================================== >>>RCS file: /usr/cvs/src/etc/defaults/rc.conf,v >>>retrieving revision 1.235 >>>diff -u -p -r1.235 rc.conf >>>--- defaults/rc.conf 15 Dec 2004 12:39:28 -0000 1.235 >>>+++ defaults/rc.conf 7 Jan 2005 00:30:49 -0000 >>>@@ -443,6 +443,8 @@ linux_enable="NO" # Linux binary compati >>>svr4_enable="NO" # SysVR4 emulation loaded at startup (or NO). >>>osf1_enable="NO" # Alpha OSF/1 emulation loaded at startup (or NO). >>>clear_tmp_enable="NO" # Clear /tmp at startup. >>>+clear_tmp_xdirs="/tmp/.X11-unix /tmp/.font-unix /tmp/.ICE-unix" >>>+ # Directories needed by X11 >>>ldconfig_insecure="NO" # Set to YES to disable ldconfig security >>>checks >>>ldconfig_paths="/usr/lib/compat /usr/X11R6/lib /usr/local/lib >>>/usr/local/lib/compat/pkg" >>> # shared library search paths >>> >>> >>> >>> >>> >>I recall putting this in a conf PR, try a follow-up. >> >>But I think your patch is a little bit wrong >> >>I never like the way X11 is taken by /etc/rc.d/cleartmp. none must be >>do after the run_rc_command. >> >> > >That's easy enough to fix. > > > >>If we need do this from the base system (Thing that I doubt more and >>more), this must be implementing a new /etc/rc.d/clearx11tmp (this may >>be do in the main /etc/rc.d/cleartmp, like in sendmail), with all the bits: >>clear_x11tmp_enable, clear_x11tmp_dirs, ... >> >>But I must point that: >> >>X11 is now mostly a ports thing, not a base system component. If this >>can be take from ports (I send-pr this also), this must be the path to >>the solution. I put a simple script from libs, but I can work and rcNG >>enabled thing if prefered. >> >>This is not what x11 really needs. x11 only needs some like this: mkdir >>-p ... && chown root:wheel ... && chmod 01777 ... . this may be >>prefered by the x11 team. >> >>This can be taken both from base and ports without too much problem. >>The only secondary effect of this I know is that you may polite /tmp >>entries twice, with is not a real pain to the whole boot process. >> >> > >My worry with using your patch is that localpkg is run quite late in the >startup process, well after X may have tried to start if xdm is run from >/etc/ttys. If package startup scripts could run anywhere in the order, >a script in the port would be obvious solution, but that's not the case. > >-- Brooks > > > You're molsty wrong. init launch gettys after rc has finished (and also localpkg). -- josemi From owner-freebsd-x11@FreeBSD.ORG Sun Jan 9 17:45:06 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 795B516A4CE; Sun, 9 Jan 2005 17:45:06 +0000 (GMT) Received: from 212.106.238.57.adsl.jazztel.es (212.106.238.57.adsl.jazztel.es [212.106.238.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83F1D43D2F; Sun, 9 Jan 2005 17:45:05 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from [192.168.254.16] (orion.redesjm.local [192.168.254.16]) j09Hj1H1000777; Sun, 9 Jan 2005 18:45:03 +0100 (CET) (envelope-from freebsd@redesjm.local) Message-ID: <41E16D9C.3010100@redesjm.local> Date: Sun, 09 Jan 2005 18:45:00 +0100 From: Jose M Rodriguez User-Agent: Mozilla Thunderbird 1.0 (X11/20050106) X-Accept-Language: es-es, es MIME-Version: 1.0 To: Pawel Worach References: <41DDC4F2.5090709@yahoo.com> <20050107003806.GA14003@odin.ac.hmc.edu> <41DE5242.4030606@redesjm.local> <20050107182024.GB30931@odin.ac.hmc.edu> <41DED3DA.1040506@telia.com> In-Reply-To: <41DED3DA.1040506@telia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.29.0.5; VDF: 6.29.0.31; host: antares.redesjm.local) cc: Rob cc: freebsd-current cc: x11@freebsd.org Subject: Re: Xorg ICE vs. Xfce4 (4.2-RC3) needs fixing /etc/rc.d/cleartmp X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2005 17:45:06 -0000 Pawel Worach escribió: > Brooks Davis wrote: > >> My worry with using your patch is that localpkg is run quite late in the >> startup process, well after X may have tried to start if xdm is run from >> /etc/ttys. If package startup scripts could run anywhere in the order, >> a script in the port would be obvious solution, but that's not the case. > > > Another issue I see with doing this in localpkg is that on a diskless > client > that shares /usr with the server it's common to set local_startup="" for > the client so that it doesn't start all the stuff you have installed > on the > server. This issue is smaller today now that more ports use rcNG. > >> >> -- Brooks >> > Not here, working great. But your proposition main problem is the time to go HEAD -> RELENG_5 -> RELENG_4. This can take months to go RELENG_5 and never to RELENG_4. Also, as I said, you may polite This. What cleartmp do now is a pure hack. What you propose is twice. If this must to HEAD, it must be adapted to rcNG rules. -- josemi From owner-freebsd-x11@FreeBSD.ORG Sun Jan 9 22:50:43 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 20BBA16A4CF for ; Sun, 9 Jan 2005 22:50:43 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id B557843D39 for ; Sun, 9 Jan 2005 22:50:40 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id A4AE051377; Sun, 9 Jan 2005 14:50:30 -0800 (PST) Date: Sun, 9 Jan 2005 14:50:30 -0800 From: Kris Kennaway To: x11@FreeBSD.org Message-ID: <20050109225030.GA76426@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: Xaw3d pkg-message out-of-date X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2005 22:50:43 -0000 --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline ******************************************************************* If you want Xaw3d to replace the default Athena Widget Set so most X applications will get a 3-D look, do this (as root): cd /usr/X11R6/lib mv libXaw.so.6 libXaw2d.so.6 ln -s libXaw3d.so.6 libXaw.so.6 ******************************************************************* XAWVER is now 8 for xorg, so the instructions are wrong. Kris --wac7ysb48OaltWcw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFB4bU2Wry0BWjoQKURAj0GAJ4meHPxYAT8GcBrjSWeErMyqaMYHACg4L7u wOZ9meniUI4dgQTCLdi1asI= =P+Lr -----END PGP SIGNATURE----- --wac7ysb48OaltWcw-- From owner-freebsd-x11@FreeBSD.ORG Sun Jan 9 22:51:59 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6A9116A4CE for ; Sun, 9 Jan 2005 22:51:59 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1CB943D31 for ; Sun, 9 Jan 2005 22:51:56 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 734C2512FC; Sun, 9 Jan 2005 14:51:47 -0800 (PST) Date: Sun, 9 Jan 2005 14:51:47 -0800 From: Kris Kennaway To: x11@FreeBSD.org Message-ID: <20050109225147.GA76457@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="45Z9DzgjV8m4Oswq" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: Xaw3d PORTVERSION bump X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2005 22:51:59 -0000 --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Also, I think Xaw3d should have received a PORTVERSION bump because the shlib version changed, and things that depended on it now do not upgrade correctly with portupgrade because it doesn't know they should be rebuilt. Kris --45Z9DzgjV8m4Oswq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFB4bWDWry0BWjoQKURAgh3AJ9uuwGKyZ0wQIcRSRpc1witviwaVQCfSbKJ OGGIku1oM6EumVti2SnrJ/I= =jYEZ -----END PGP SIGNATURE----- --45Z9DzgjV8m4Oswq-- From owner-freebsd-x11@FreeBSD.ORG Mon Jan 10 01:47:04 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B95D16A4CE; Mon, 10 Jan 2005 01:47:04 +0000 (GMT) Received: from leguin.anholt.net (69-30-77-85.dq1sn.easystreet.com [69.30.77.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07B0B43D39; Mon, 10 Jan 2005 01:47:02 +0000 (GMT) (envelope-from eta@lclark.edu) Received: from leguin.anholt.net (localhost [127.0.0.1]) by leguin.anholt.net (8.13.1/8.13.1) with ESMTP id j0A1kt2I060781; Sun, 9 Jan 2005 17:46:55 -0800 (PST) (envelope-from eta@lclark.edu) Received: (from anholt@localhost) by leguin.anholt.net (8.13.1/8.13.1/Submit) id j0A1kstp060749; Sun, 9 Jan 2005 17:46:54 -0800 (PST) (envelope-from eta@lclark.edu) X-Authentication-Warning: leguin.anholt.net: anholt set sender to eta@lclark.edu using -f From: Eric Anholt To: x11@FreeBSD.org, ports@FreeBSD.org Content-Type: multipart/mixed; boundary="=-djNu0bw2gq0d2b6kW9Nw" Date: Sun, 09 Jan 2005 17:46:54 -0800 Message-Id: <1105321614.8452.54.camel@leguin> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 FreeBSD GNOME Team Port Subject: x11 /tmp preparation rc.d script X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 01:47:04 -0000 --=-djNu0bw2gq0d2b6kW9Nw Content-Type: text/plain Content-Transfer-Encoding: 7bit Attached are my proposed patches to deal with the X11 ICE issue. To review, it's required because having .ICE not owned by root is a security issue, one that's been papered over with a printed warning and sleep(5) in libICE for years, and has recently been changed into an actual error by the X.Org folks. The question is whether to stick it in base or in ports: In favor of ports: - Seems like the proper place. Nothing happens for non-X11 users. In favor of base: - Would either need to make a separate port just for the script, or keep the script in at least 3 separate ports, disregarding the cleanup of servers which might make for more ports affected. - From ports, it might get started too late in the boot process, or not at all in some installations. I decided to do it in the base system, assuming that we can spare 4 inodes, given that we already have BSD.x11-4.dist happening. Brooks's patch also allowed overriding the set of directories. I don't think that's a real issue, and the clutter in /etc/defaults/rc.conf is worse. I also think that cleartmp probably shouldn't be overloaded with X stuff, though there's still the BEFORE: preparex11 line, which I'm unsure of. So, attached are proposed patches for 6-current and 5-stable. I haven't done a real install of them because my systems are out of date, but I wanted to get this out there for review so it can go into CVS soon after I test installing. If they're good, they would be merged to RELENG_5_3 and older, I hope, due to the security implications. Any comments? -- Eric Anholt eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org --=-djNu0bw2gq0d2b6kW9Nw Content-Disposition: attachment; filename=preparex11-current Content-Type: text/x-patch; name=preparex11-current; charset=ISO-8859-1 Content-Transfer-Encoding: base64 SW5kZXg6IGV0Yy9kZWZhdWx0cy9yYy5jb25mDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2hvbWUv bmN2cy9zcmMvZXRjL2RlZmF1bHRzL3JjLmNvbmYsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjIz NQ0KZGlmZiAtdSAtcjEuMjM1IHJjLmNvbmYNCi0tLSBldGMvZGVmYXVsdHMvcmMuY29uZgkxNSBE ZWMgMjAwNCAxMjozOToyOCAtMDAwMAkxLjIzNQ0KKysrIGV0Yy9kZWZhdWx0cy9yYy5jb25mCTEw IEphbiAyMDA1IDAxOjI1OjM1IC0wMDAwDQpAQCAtNDQzLDYgKzQ0Myw3IEBADQogc3ZyNF9lbmFi bGU9Ik5PIgkjIFN5c1ZSNCBlbXVsYXRpb24gbG9hZGVkIGF0IHN0YXJ0dXAgKG9yIE5PKS4NCiBv c2YxX2VuYWJsZT0iTk8iCSMgQWxwaGEgT1NGLzEgZW11bGF0aW9uIGxvYWRlZCBhdCBzdGFydHVw IChvciBOTykuDQogY2xlYXJfdG1wX2VuYWJsZT0iTk8iCSMgQ2xlYXIgL3RtcCBhdCBzdGFydHVw Lg0KK3ByZXBhcmVfeDExX2VuYWJsZT0iWUVTIiAjIENsZWFuIGFuZCByZWNyZWF0ZSBkaXJlY3Rv cmllcyBuZWNlc3NhcnkgZm9yIFgxMS4NCiBsZGNvbmZpZ19pbnNlY3VyZT0iTk8iCSMgU2V0IHRv IFlFUyB0byBkaXNhYmxlIGxkY29uZmlnIHNlY3VyaXR5IGNoZWNrcw0KIGxkY29uZmlnX3BhdGhz PSIvdXNyL2xpYi9jb21wYXQgL3Vzci9YMTFSNi9saWIgL3Vzci9sb2NhbC9saWIgL3Vzci9sb2Nh bC9saWIvY29tcGF0L3BrZyINCiAJCQkjIHNoYXJlZCBsaWJyYXJ5IHNlYXJjaCBwYXRocw0KSW5k ZXg6IGV0Yy9yYy5kL01ha2VmaWxlDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9z cmMvZXRjL3JjLmQvTWFrZWZpbGUsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjQ3DQpkaWZmIC11 IC1yMS40NyBNYWtlZmlsZQ0KLS0tIGV0Yy9yYy5kL01ha2VmaWxlCTE2IE5vdiAyMDA0IDA0OjIw OjA5IC0wMDAwCTEuNDcNCisrKyBldGMvcmMuZC9NYWtlZmlsZQkxMCBKYW4gMjAwNSAwMDo1NTo0 MCAtMDAwMA0KQEAgLTI2LDcgKzI2LDcgQEANCiAJbmZzbG9ja2luZyBuZnNzZXJ2ZXIgbmlzZG9t YWluIG5zc3dpdGNoIG50cGQgbnRwZGF0ZSBcDQogCW90aGVybXRhIFwNCiAJcGNjYXJkIHBjdnQg cGYgcGZsb2cgXA0KLQlwb3dlcl9wcm9maWxlIHBwcC11c2VyIHBwcG9lZCBwcmVzZWVkcmFuZG9t IHB3Y2hlY2sgXA0KKwlwb3dlcl9wcm9maWxlIHBwcC11c2VyIHBwcG9lZCBwcmVwYXJleDExIHBy ZXNlZWRyYW5kb20gcHdjaGVjayBcDQogCXF1b3RhIFwNCiAJcmFtZGlzayByYW1kaXNrLW93biBy YW5kb20gcmFycGQgcmNjb25mLnNoIHJlc29sdiByb290IFwNCiAJcm91dGU2ZCByb3V0ZWQgcm91 dGluZyBycGNiaW5kIHJ0YWR2ZCByd2hvIFwNCkluZGV4OiBldGMvcmMuZC9jbGVhcnRtcA0KPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL2V0Yy9yYy5kL2NsZWFydG1wLHYNCnJl dHJpZXZpbmcgcmV2aXNpb24gMS4xMQ0KZGlmZiAtdSAtcjEuMTEgY2xlYXJ0bXANCi0tLSBldGMv cmMuZC9jbGVhcnRtcAk3IE9jdCAyMDA0IDEzOjU1OjI1IC0wMDAwCTEuMTENCisrKyBldGMvcmMu ZC9jbGVhcnRtcAkxMCBKYW4gMjAwNSAwMTowMDowOCAtMDAwMA0KQEAgLTYsNyArNiw3IEBADQog DQogIyBQUk9WSURFOiBjbGVhcnRtcA0KICMgUkVRVUlSRTogbW91bnRjcml0cmVtb3RlIHRtcA0K LSMgQkVGT1JFOiBEQUVNT04NCisjIEJFRk9SRTogREFFTU9OIHByZXBhcmV4MTENCiANCiAuIC9l dGMvcmMuc3Vicg0KIA0KQEAgLTMwLDEwICszMCwzIEBADQogDQogbG9hZF9yY19jb25maWcgJG5h bWUNCiBydW5fcmNfY29tbWFuZCAiJDEiDQotDQotIyBSZW1vdmUgWCBsb2NrIGZpbGVzLCBzaW5j ZSB0aGV5IHdpbGwgcHJldmVudCB5b3UgZnJvbQ0KLSMgcmVzdGFydGluZyBYDQotIw0KLXJtIC1m IC90bXAvLlhbMC05XS1sb2NrDQotcm0gLWZyIC90bXAvLlgxMS11bml4DQotbWtkaXIgLW0gMTc3 NyAvdG1wLy5YMTEtdW5peA0KSW5kZXg6IGV0Yy9yYy5kL3ByZXBhcmV4MTENCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N ClJDUyBmaWxlOiBldGMvcmMuZC9wcmVwYXJleDExDQpkaWZmIC1OIGV0Yy9yYy5kL3ByZXBhcmV4 MTENCi0tLSAvZGV2L251bGwJMSBKYW4gMTk3MCAwMDowMDowMCAtMDAwMA0KKysrIGV0Yy9yYy5k L3ByZXBhcmV4MTEJMTAgSmFuIDIwMDUgMDE6MTA6NDQgLTAwMDANCkBAIC0wLDAgKzEsMjcgQEAN CisjIS9iaW4vc2gNCisjDQorIyAkRnJlZUJTRCQNCisjDQorDQorIyBQUk9WSURFOiBwcmVwYXJl eDExDQorIyBSRVFVSVJFOiBtb3VudGFsbA0KKyMgQkVGT1JFOiBEQUVNT04NCisjIEtFWVdPUkQ6 IEZyZWVCU0QgTmV0QlNEDQorDQorLiAvZXRjL3JjLnN1YnINCisNCituYW1lPSJwcmVwYXJleDEx Ig0KK3JjdmFyPWBzZXRfcmN2YXIgcHJlcGFyZV94MTFgDQorc3RhcnRfY21kPSJwcmVwYXJleDEx X3N0YXJ0Ig0KK3N0b3BfY21kPSI6Ig0KKw0KK3ByZXBhcmV4MTFfc3RhcnQoKQ0KK3sNCisJZWNo byAiUHJlcGFyaW5nIC90bXAgZm9yIFgxMSBhcHBsaWNhdGlvbnMuIg0KKwlybSAtZiAvdG1wLy5Y Ki1sb2NrDQorCXJtIC1mciAvdG1wLy5YMTEtdW5peCAvdG1wLy5mb250LXVuaXggL3RtcC8uSUNF LXVuaXgNCisJbWtkaXIgLW0gMTc3NyAvdG1wLy5YMTEtdW5peCAvdG1wLy5mb250LXVuaXggL3Rt cC8uSUNFLXVuaXgNCit9DQorDQorbG9hZF9yY19jb25maWcgJG5hbWUNCitydW5fcmNfY29tbWFu ZCAiJDEiDQpJbmRleDogc2hhcmUvbWFuL21hbjUvcmMuY29uZi41DQo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1Mg ZmlsZTogL2hvbWUvbmN2cy9zcmMvc2hhcmUvbWFuL21hbjUvcmMuY29uZi41LHYNCnJldHJpZXZp bmcgcmV2aXNpb24gMS4yNDENCmRpZmYgLXUgLXIxLjI0MSByYy5jb25mLjUNCi0tLSBzaGFyZS9t YW4vbWFuNS9yYy5jb25mLjUJNSBKYW4gMjAwNSAwOTo1MjoxMiAtMDAwMAkxLjI0MQ0KKysrIHNo YXJlL21hbi9tYW41L3JjLmNvbmYuNQkxMCBKYW4gMjAwNSAwMToyNTozNiAtMDAwMA0KQEAgLTI1 ODYsNiArMjU4NiwxNyBAQA0KIHRvIGhhdmUNCiAuUGEgL3RtcA0KIGNsZWFuZWQgYXQgc3RhcnR1 cC4NCisuSXQgVmEgcHJlcGFyZV94MTFfZW5hYmxlDQorLlBxIFZ0IGJvb2wNCitTZXQgdG8NCisu RHEgTGkgTk8NCit0byBkaXNhYmxlIHJlbW92aW5nIHN0YWxlIFggc2VydmVyIGxvY2tmaWxlcyBh bmQgZGlzYWJsZSByZW1vdmluZyBhbmQgcmVjcmVhdGluZw0KKy5QYSAvdG1wLy5JQ0UtdW5peCAs DQorLlBhIC90bXAvLlgxMS11bml4ICwNCithbmQNCisuUGEgL3RtcC8uZm9udC11bml4DQorYXQg c3RhcnR1cC4gIE1heSBiZSBhIHNlY3VyaXR5IGlzc3VlIGlmIFgxMSBhcHBsaWNhdGlvbnMgYXJl IHVzZWQgd2l0aCB0aGlzDQorZGlzYWJsZWQuDQogLkl0IFZhIGxkY29uZmlnX3BhdGhzDQogLlBx IFZ0IHN0cg0KIFNldCB0byB0aGUgbGlzdCBvZiBzaGFyZWQgbGlicmFyeSBwYXRocyB0byB1c2Ug d2l0aA0K --=-djNu0bw2gq0d2b6kW9Nw Content-Disposition: attachment; filename=preparex11-stable Content-Type: text/x-patch; name=preparex11-stable; charset=ISO-8859-1 Content-Transfer-Encoding: base64 SW5kZXg6IGV0Yy9kZWZhdWx0cy9yYy5jb25mDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2hvbWUv bmN2cy9zcmMvZXRjL2RlZmF1bHRzL3JjLmNvbmYsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjIx Mi4yLjkNCmRpZmYgLXUgLXIxLjIxMi4yLjkgcmMuY29uZg0KLS0tIGV0Yy9kZWZhdWx0cy9yYy5j b25mCTMgSmFuIDIwMDUgMTI6NDE6MzkgLTAwMDAJMS4yMTIuMi45DQorKysgZXRjL2RlZmF1bHRz L3JjLmNvbmYJMTAgSmFuIDIwMDUgMDE6MTA6MTUgLTAwMDANCkBAIC00MzgsNiArNDM4LDcgQEAN CiBzdnI0X2VuYWJsZT0iTk8iCSMgU3lzVlI0IGVtdWxhdGlvbiBsb2FkZWQgYXQgc3RhcnR1cCAo b3IgTk8pLg0KIG9zZjFfZW5hYmxlPSJOTyIJIyBBbHBoYSBPU0YvMSBlbXVsYXRpb24gbG9hZGVk IGF0IHN0YXJ0dXAgKG9yIE5PKS4NCiBjbGVhcl90bXBfZW5hYmxlPSJOTyIJIyBDbGVhciAvdG1w IGF0IHN0YXJ0dXAuDQorcHJlcGFyZV94MTFfZW5hYmxlPSJZRVMiICMgQ2xlYW4gYW5kIHJlY3Jl YXRlIGRpcmVjdG9yaWVzIG5lY2Vzc2FyeSBmb3IgWDExLg0KIGxkY29uZmlnX2luc2VjdXJlPSJO TyIJIyBTZXQgdG8gWUVTIHRvIGRpc2FibGUgbGRjb25maWcgc2VjdXJpdHkgY2hlY2tzDQogbGRj b25maWdfcGF0aHM9Ii91c3IvbGliL2NvbXBhdCAvdXNyL1gxMVI2L2xpYiAvdXNyL2xvY2FsL2xp YiINCiAJCQkjIHNoYXJlZCBsaWJyYXJ5IHNlYXJjaCBwYXRocw0KSW5kZXg6IGV0Yy9yYy5kL01h a2VmaWxlDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvZXRjL3JjLmQvTWFr ZWZpbGUsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjQxLjIuMQ0KZGlmZiAtdSAtcjEuNDEuMi4x IE1ha2VmaWxlDQotLS0gZXRjL3JjLmQvTWFrZWZpbGUJMTQgT2N0IDIwMDQgMDQ6MzY6MTUgLTAw MDAJMS40MS4yLjENCisrKyBldGMvcmMuZC9NYWtlZmlsZQkxMCBKYW4gMjAwNSAwMToxODoyMiAt MDAwMA0KQEAgLTI2LDcgKzI2LDcgQEANCiAJbmZzbG9ja2luZyBuZnNzZXJ2ZXIgbmlzZG9tYWlu IG5zc3dpdGNoIG50cGQgbnRwZGF0ZSBcDQogCW90aGVybXRhIFwNCiAJcGNjYXJkIHBjdnQgcGYg cGZsb2cgcHJlc2VlZHJhbmRvbSBcDQotCXBvd2VyX3Byb2ZpbGUgcHBwLXVzZXIgcHBwb2VkIHB3 Y2hlY2sgXA0KKwlwb3dlcl9wcm9maWxlIHBwcC11c2VyIHBwcG9lZCBwcmVwYXJleDExIHB3Y2hl Y2sgXA0KIAlxdW90YSBcDQogCXJhbmRvbSByYXJwZCByY2NvbmYuc2ggcmVzb2x2IHJvb3QgXA0K IAlyb3V0ZTZkIHJvdXRlZCByb3V0aW5nIHJwY2JpbmQgcnRhZHZkIHJ3aG8gXA0KSW5kZXg6IGV0 Yy9yYy5kL2NsZWFydG1wDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvZXRj L3JjLmQvY2xlYXJ0bXAsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjEwLjIuMQ0KZGlmZiAtdSAt cjEuMTAuMi4xIGNsZWFydG1wDQotLS0gZXRjL3JjLmQvY2xlYXJ0bXAJMTAgT2N0IDIwMDQgMDk6 NTA6NTMgLTAwMDAJMS4xMC4yLjENCisrKyBldGMvcmMuZC9jbGVhcnRtcAkxMCBKYW4gMjAwNSAw MToyNjo0NSAtMDAwMA0KQEAgLTYsNyArNiw3IEBADQogDQogIyBQUk9WSURFOiBjbGVhcnRtcA0K ICMgUkVRVUlSRTogbW91bnRjcml0cmVtb3RlIHRtcA0KLSMgQkVGT1JFOiBEQUVNT04NCisjIEJF Rk9SRTogREFFTU9OIHByZXBhcmV4MTENCiANCiAuIC9ldGMvcmMuc3Vicg0KIA0KQEAgLTMwLDEw ICszMCwzIEBADQogDQogbG9hZF9yY19jb25maWcgJG5hbWUNCiBydW5fcmNfY29tbWFuZCAiJDEi DQotDQotIyBSZW1vdmUgWCBsb2NrIGZpbGVzLCBzaW5jZSB0aGV5IHdpbGwgcHJldmVudCB5b3Ug ZnJvbQ0KLSMgcmVzdGFydGluZyBYDQotIw0KLXJtIC1mIC90bXAvLlhbMC05XS1sb2NrDQotcm0g LWZyIC90bXAvLlgxMS11bml4DQotbWtkaXIgLW0gMTc3NyAvdG1wLy5YMTEtdW5peA0KSW5kZXg6 IGV0Yy9yYy5kL3ByZXBhcmV4MTENCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJDUyBmaWxlOiBldGMvcmMuZC9wcmVw YXJleDExDQpkaWZmIC1OIGV0Yy9yYy5kL3ByZXBhcmV4MTENCi0tLSAvZGV2L251bGwJMSBKYW4g MTk3MCAwMDowMDowMCAtMDAwMA0KKysrIGV0Yy9yYy5kL3ByZXBhcmV4MTEJMTAgSmFuIDIwMDUg MDE6MTA6NTYgLTAwMDANCkBAIC0wLDAgKzEsMjcgQEANCisjIS9iaW4vc2gNCisjDQorIyAkRnJl ZUJTRCQNCisjDQorDQorIyBQUk9WSURFOiBwcmVwYXJleDExDQorIyBSRVFVSVJFOiBtb3VudGFs bA0KKyMgQkVGT1JFOiBEQUVNT04NCisjIEtFWVdPUkQ6IEZyZWVCU0QgTmV0QlNEDQorDQorLiAv ZXRjL3JjLnN1YnINCisNCituYW1lPSJwcmVwYXJleDExIg0KK3JjdmFyPWBzZXRfcmN2YXIgcHJl cGFyZV94MTFgDQorc3RhcnRfY21kPSJwcmVwYXJleDExX3N0YXJ0Ig0KK3N0b3BfY21kPSI6Ig0K Kw0KK3ByZXBhcmV4MTFfc3RhcnQoKQ0KK3sNCisJZWNobyAiUHJlcGFyaW5nIC90bXAgZm9yIFgx MSBhcHBsaWNhdGlvbnMuIg0KKwlybSAtZiAvdG1wLy5YKi1sb2NrDQorCXJtIC1mciAvdG1wLy5Y MTEtdW5peCAvdG1wLy5mb250LXVuaXggL3RtcC8uSUNFLXVuaXgNCisJbWtkaXIgLW0gMTc3NyAv dG1wLy5YMTEtdW5peCAvdG1wLy5mb250LXVuaXggL3RtcC8uSUNFLXVuaXgNCit9DQorDQorbG9h ZF9yY19jb25maWcgJG5hbWUNCitydW5fcmNfY29tbWFuZCAiJDEiDQpJbmRleDogc2hhcmUvbWFu L21hbjUvcmMuY29uZi41DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc2hh cmUvbWFuL21hbjUvcmMuY29uZi41LHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4yMjEuMi44DQpk aWZmIC11IC1yMS4yMjEuMi44IHJjLmNvbmYuNQ0KLS0tIHNoYXJlL21hbi9tYW41L3JjLmNvbmYu NQk1IEphbiAyMDA1IDA4OjMxOjE5IC0wMDAwCTEuMjIxLjIuOA0KKysrIHNoYXJlL21hbi9tYW41 L3JjLmNvbmYuNQkxMCBKYW4gMjAwNSAwMToyNTo0NyAtMDAwMA0KQEAgLTI1ODYsNiArMjU4Niwx NyBAQA0KIHRvIGhhdmUNCiAuUGEgL3RtcA0KIGNsZWFuZWQgYXQgc3RhcnR1cC4NCisuSXQgVmEg cHJlcGFyZV94MTFfZW5hYmxlDQorLlBxIFZ0IGJvb2wNCitTZXQgdG8NCisuRHEgTGkgTk8NCit0 byBkaXNhYmxlIHJlbW92aW5nIHN0YWxlIFggc2VydmVyIGxvY2tmaWxlcyBhbmQgZGlzYWJsZSBy ZW1vdmluZyBhbmQgcmVjcmVhdGluZw0KKy5QYSAvdG1wLy5JQ0UtdW5peCAsDQorLlBhIC90bXAv LlgxMS11bml4ICwNCithbmQNCisuUGEgL3RtcC8uZm9udC11bml4DQorYXQgc3RhcnR1cC4gIE1h eSBiZSBhIHNlY3VyaXR5IGlzc3VlIGlmIFgxMSBhcHBsaWNhdGlvbnMgYXJlIHVzZWQgd2l0aCB0 aGlzDQorZGlzYWJsZWQuDQogLkl0IFZhIGxkY29uZmlnX3BhdGhzDQogLlBxIFZ0IHN0cg0KIFNl dCB0byB0aGUgbGlzdCBvZiBzaGFyZWQgbGlicmFyeSBwYXRocyB0byB1c2Ugd2l0aA0K --=-djNu0bw2gq0d2b6kW9Nw-- From owner-freebsd-x11@FreeBSD.ORG Mon Jan 10 06:58:56 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 45EA216A4CE; Mon, 10 Jan 2005 06:58:56 +0000 (GMT) Received: from mailhub01.unibe.ch (mailhub01.unibe.ch [130.92.9.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B7FE43D31; Mon, 10 Jan 2005 06:58:55 +0000 (GMT) (envelope-from roth@droopy.unibe.ch) Received: from localhost (scanhub02.unibe.ch [130.92.254.66]) by mailhub01.unibe.ch (Postfix) with ESMTP id 7665F25BAD2; Mon, 10 Jan 2005 07:58:53 +0100 (MET) Received: from mailhub01.unibe.ch ([130.92.9.52]) by localhost (scanhub02.unibe.ch [130.92.254.66]) (amavisd-new, port 10024) with LMTP id 07454-01-25; Mon, 10 Jan 2005 07:58:49 +0100 (CET) Received: from asterix.unibe.ch (asterix.unibe.ch [130.92.64.4]) by mailhub01.unibe.ch (Postfix) with ESMTP id 7534C25BAC5; Mon, 10 Jan 2005 07:58:51 +0100 (MET) Received: from droopy.unibe.ch (droopy [130.92.64.20]) by asterix.unibe.ch (8.11.7p1+Sun/8.11.7) with ESMTP id j0A6wpq03859; Mon, 10 Jan 2005 07:58:51 +0100 (MET) Received: (from roth@localhost) by droopy.unibe.ch (8.12.10+Sun/8.12.9/Submit) id j0A6wopw005817; Mon, 10 Jan 2005 07:58:50 +0100 (MET) Date: Mon, 10 Jan 2005 07:58:50 +0100 From: Tobias Roth To: Eric Anholt Message-ID: <20050110065850.GA5797@droopy.unibe.ch> References: <1105321614.8452.54.camel@leguin> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1105321614.8452.54.camel@leguin> User-Agent: Mutt/1.4i X-message-flag: Warning! Using Outlook is insecure and promotes virus distribution. Please use a different email client. X-Virus-checked: by University of Berne cc: ports@freebsd.org cc: x11@freebsd.org Subject: Re: x11 /tmp preparation rc.d script X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 06:58:56 -0000 On Sun, Jan 09, 2005 at 05:46:54PM -0800, Eric Anholt wrote: > > Any comments? one small detail: since 5.3, KEYWORD: FreeBSD NetBSD is no longer used. the rest looks ok to me (i didn't apply it though). cheers, t. From owner-freebsd-x11@FreeBSD.ORG Mon Jan 10 08:27:11 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77DEF16A4CE; Mon, 10 Jan 2005 08:27:11 +0000 (GMT) Received: from 212.106.238.57.adsl.jazztel.es (212.106.238.57.adsl.jazztel.es [212.106.238.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id B65D343D1F; Mon, 10 Jan 2005 08:27:09 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from [192.168.254.16] (orion.redesjm.local [192.168.254.16]) j0A8R433019277; Mon, 10 Jan 2005 09:27:06 +0100 (CET) (envelope-from freebsd@redesjm.local) Message-ID: <41E23C58.10606@redesjm.local> Date: Mon, 10 Jan 2005 09:27:04 +0100 From: Jose M Rodriguez User-Agent: Mozilla Thunderbird 1.0 (X11/20050106) X-Accept-Language: es-es, es MIME-Version: 1.0 To: Eric Anholt References: <1105321614.8452.54.camel@leguin> In-Reply-To: <1105321614.8452.54.camel@leguin> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.29.0.5; VDF: 6.29.0.31; host: antares.redesjm.local) cc: ports@FreeBSD.org cc: x11@FreeBSD.org Subject: Re: x11 /tmp preparation rc.d script X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 08:27:11 -0000 Eric Anholt escribió: >Attached are my proposed patches to deal with the X11 ICE issue. To >review, it's required because having .ICE not owned by root is a >security issue, one that's been papered over with a printed warning and >sleep(5) in libICE for years, and has recently been changed into an >actual error by the X.Org folks. > >The question is whether to stick it in base or in ports: > >In favor of ports: > - Seems like the proper place. Nothing happens for non-X11 users. >In favor of base: > - Would either need to make a separate port just for the script, or > keep the script in at least 3 separate ports, disregarding the > cleanup of servers which might make for more ports affected. > > Well, seems that this is really needed only from xorg-libs. That must be needed also from XFree86-4-libs, but this because we maintain two X11 ports system. > - From ports, it might get started too late in the boot process, or > not at all in some installations. > > This is not a real thread. Please, note cases. >I decided to do it in the base system, assuming that we can spare 4 >inodes, given that we already have BSD.x11-4.dist happening. > > What I can't understand is the matter of choice. Seems that having both solutions (ports and base) is not dangerous. You may need a ms timer to take this in account. I think that the two solutions must be targeted, and the ports based one will be deprecated on time only when all our base targets (We must support Xorg also on RELENG_4, al last, while this is possible). If you go to a rcNG script, make this have auto defaults, and install it from ports after OS_VERSION test. You may lose this code from ports when all the possible targets of Xorg have this on base. >Brooks's patch also allowed overriding the set of directories. I don't >think that's a real issue, and the clutter in /etc/defaults/rc.conf is >worse. I also think that cleartmp probably shouldn't be overloaded with >X stuff, though there's still the BEFORE: preparex11 line, which I'm >unsure of. > >So, attached are proposed patches for 6-current and 5-stable. I haven't >done a real install of them because my systems are out of date, but I >wanted to get this out there for review so it can go into CVS soon after >I test installing. If they're good, they would be merged to RELENG_5_3 >and older, I hope, due to the security implications. > >Any comments? > > > >------------------------------------------------------------------------ > >Index: etc/defaults/rc.conf >=================================================================== >RCS file: /home/ncvs/src/etc/defaults/rc.conf,v >retrieving revision 1.235 >diff -u -r1.235 rc.conf >--- etc/defaults/rc.conf 15 Dec 2004 12:39:28 -0000 1.235 >+++ etc/defaults/rc.conf 10 Jan 2005 01:25:35 -0000 >@@ -443,6 +443,7 @@ > svr4_enable="NO" # SysVR4 emulation loaded at startup (or NO). > osf1_enable="NO" # Alpha OSF/1 emulation loaded at startup (or NO). > clear_tmp_enable="NO" # Clear /tmp at startup. >+prepare_x11_enable="YES" # Clean and recreate directories necessary for X11. > ldconfig_insecure="NO" # Set to YES to disable ldconfig security checks > ldconfig_paths="/usr/lib/compat /usr/X11R6/lib /usr/local/lib /usr/local/lib/compat/pkg" > # shared library search paths >Index: etc/rc.d/Makefile >=================================================================== >RCS file: /home/ncvs/src/etc/rc.d/Makefile,v >retrieving revision 1.47 >diff -u -r1.47 Makefile >--- etc/rc.d/Makefile 16 Nov 2004 04:20:09 -0000 1.47 >+++ etc/rc.d/Makefile 10 Jan 2005 00:55:40 -0000 >@@ -26,7 +26,7 @@ > nfslocking nfsserver nisdomain nsswitch ntpd ntpdate \ > othermta \ > pccard pcvt pf pflog \ >- power_profile ppp-user pppoed preseedrandom pwcheck \ >+ power_profile ppp-user pppoed preparex11 preseedrandom pwcheck \ > quota \ > ramdisk ramdisk-own random rarpd rcconf.sh resolv root \ > route6d routed routing rpcbind rtadvd rwho \ >Index: etc/rc.d/cleartmp >=================================================================== >RCS file: /home/ncvs/src/etc/rc.d/cleartmp,v >retrieving revision 1.11 >diff -u -r1.11 cleartmp >--- etc/rc.d/cleartmp 7 Oct 2004 13:55:25 -0000 1.11 >+++ etc/rc.d/cleartmp 10 Jan 2005 01:00:08 -0000 >@@ -6,7 +6,7 @@ > > # PROVIDE: cleartmp > # REQUIRE: mountcritremote tmp >-# BEFORE: DAEMON >+# BEFORE: DAEMON preparex11 > > I think you may take this better from your new script. rcNG also support and REQUIRE/AFTER keyword. I think you must take preparex11 _after_ cleartmp The only 'consumers' of this I know are xdm related scripts on localpkg and gettys from init after rc has finished. > > . /etc/rc.subr > >@@ -30,10 +30,3 @@ > > load_rc_config $name > run_rc_command "$1" >- >-# Remove X lock files, since they will prevent you from >-# restarting X >-# >-rm -f /tmp/.X[0-9]-lock >-rm -fr /tmp/.X11-unix >-mkdir -m 1777 /tmp/.X11-unix >Index: etc/rc.d/preparex11 >=================================================================== >RCS file: etc/rc.d/preparex11 >diff -N etc/rc.d/preparex11 >--- /dev/null 1 Jan 1970 00:00:00 -0000 >+++ etc/rc.d/preparex11 10 Jan 2005 01:10:44 -0000 >@@ -0,0 +1,27 @@ >+#!/bin/sh >+# >+# $FreeBSD$ >+# >+ >+# PROVIDE: preparex11 > > consider REQUIRE: mountall cleartmp >+# REQUIRE: mountall >+# BEFORE: DAEMON > > We have lost symtem flags >+# KEYWORD: FreeBSD NetBSD > >+ >+. /etc/rc.subr >+ >+name="preparex11" >+rcvar=`set_rcvar prepare_x11` >+start_cmd="preparex11_start" >+stop_cmd=":" >+ >+preparex11_start() >+{ >+ echo "Preparing /tmp for X11 applications." >+ rm -f /tmp/.X*-lock >+ rm -fr /tmp/.X11-unix /tmp/.font-unix /tmp/.ICE-unix >+ mkdir -m 1777 /tmp/.X11-unix /tmp/.font-unix /tmp/.ICE-unix >+} >+ >+load_rc_config $name > > if you add the next auto default here, this same script will work installed from ports. Install it with, 000. name prefix, so this is take before gdm.sh or similar : ${prepare_x11_enable:="YES"} >+run_rc_command "$1" >Index: share/man/man5/rc.conf.5 >=================================================================== >RCS file: /home/ncvs/src/share/man/man5/rc.conf.5,v >retrieving revision 1.241 >diff -u -r1.241 rc.conf.5 >--- share/man/man5/rc.conf.5 5 Jan 2005 09:52:12 -0000 1.241 >+++ share/man/man5/rc.conf.5 10 Jan 2005 01:25:36 -0000 >@@ -2586,6 +2586,17 @@ > to have > .Pa /tmp > cleaned at startup. >+.It Va prepare_x11_enable >+.Pq Vt bool >+Set to >+.Dq Li NO >+to disable removing stale X server lockfiles and disable removing and recreating >+.Pa /tmp/.ICE-unix , >+.Pa /tmp/.X11-unix , >+and >+.Pa /tmp/.font-unix >+at startup. May be a security issue if X11 applications are used with this >+disabled. > .It Va ldconfig_paths > .Pq Vt str > Set to the list of shared library paths to use with > > > > -- josemi From owner-freebsd-x11@FreeBSD.ORG Mon Jan 10 08:40:51 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 89B9E16A4CE; Mon, 10 Jan 2005 08:40:51 +0000 (GMT) Received: from 212.106.238.57.adsl.jazztel.es (212.106.238.57.adsl.jazztel.es [212.106.238.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4586C43D1D; Mon, 10 Jan 2005 08:40:50 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from [192.168.254.16] (orion.redesjm.local [192.168.254.16]) j0A8elpH063389; Mon, 10 Jan 2005 09:40:47 +0100 (CET) (envelope-from freebsd@redesjm.local) Message-ID: <41E23F8F.4040701@redesjm.local> Date: Mon, 10 Jan 2005 09:40:47 +0100 From: Jose M Rodriguez User-Agent: Mozilla Thunderbird 1.0 (X11/20050106) X-Accept-Language: es-es, es MIME-Version: 1.0 To: Jose M Rodriguez References: <1105321614.8452.54.camel@leguin> <41E23C58.10606@redesjm.local> In-Reply-To: <41E23C58.10606@redesjm.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.29.0.5; VDF: 6.29.0.31; host: antares.redesjm.local) cc: ports@FreeBSD.org cc: x11@FreeBSD.org Subject: Re: x11 /tmp preparation rc.d script X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 08:40:51 -0000 Jose M Rodriguez escribió: > Eric Anholt escribió: > >> Attached are my proposed patches to deal with the X11 ICE issue. To >> review, it's required because having .ICE not owned by root is a >> security issue, one that's been papered over with a printed warning and >> sleep(5) in libICE for years, and has recently been changed into an >> actual error by the X.Org folks. >> ... As a latter think about this, consider take also periodic related fixes (We clear this directories by default) and try to get a OS_VERSION bump closest to this. -- josemi >> The question is whether to stick it in base or in ports: >> >> In favor of ports: >> - Seems like the proper place. Nothing happens for non-X11 users. >> In favor of base: >> - Would either need to make a separate port just for the script, or >> keep the script in at least 3 separate ports, disregarding the >> cleanup of servers which might make for more ports affected. >> >> > Well, seems that this is really needed only from xorg-libs. That must > be needed also from XFree86-4-libs, but this because we maintain two > X11 ports system. > >> - From ports, it might get started too late in the boot process, or >> not at all in some installations. >> >> > This is not a real thread. Please, note cases. > >> I decided to do it in the base system, assuming that we can spare 4 >> inodes, given that we already have BSD.x11-4.dist happening. >> >> > What I can't understand is the matter of choice. Seems that having > both solutions (ports and base) is not dangerous. You may need a ms > timer to take this in account. > > I think that the two solutions must be targeted, and the ports based > one will be deprecated on time only when all our base targets (We must > support Xorg also on RELENG_4, al last, while this is possible). > > If you go to a rcNG script, make this have auto defaults, and install > it from ports after OS_VERSION test. You may lose this code from > ports when all the possible targets of Xorg have this on base. > >> Brooks's patch also allowed overriding the set of directories. I don't >> think that's a real issue, and the clutter in /etc/defaults/rc.conf is >> worse. I also think that cleartmp probably shouldn't be overloaded with >> X stuff, though there's still the BEFORE: preparex11 line, which I'm >> unsure of. >> >> So, attached are proposed patches for 6-current and 5-stable. I haven't >> done a real install of them because my systems are out of date, but I >> wanted to get this out there for review so it can go into CVS soon after >> I test installing. If they're good, they would be merged to RELENG_5_3 >> and older, I hope, due to the security implications. >> >> Any comments? >> >> >> >> ------------------------------------------------------------------------ >> >> Index: etc/defaults/rc.conf >> =================================================================== >> RCS file: /home/ncvs/src/etc/defaults/rc.conf,v >> retrieving revision 1.235 >> diff -u -r1.235 rc.conf >> --- etc/defaults/rc.conf 15 Dec 2004 12:39:28 -0000 1.235 >> +++ etc/defaults/rc.conf 10 Jan 2005 01:25:35 -0000 >> @@ -443,6 +443,7 @@ >> svr4_enable="NO" # SysVR4 emulation loaded at startup (or NO). >> osf1_enable="NO" # Alpha OSF/1 emulation loaded at startup (or NO). >> clear_tmp_enable="NO" # Clear /tmp at startup. >> +prepare_x11_enable="YES" # Clean and recreate directories necessary >> for X11. >> ldconfig_insecure="NO" # Set to YES to disable ldconfig security >> checks >> ldconfig_paths="/usr/lib/compat /usr/X11R6/lib /usr/local/lib >> /usr/local/lib/compat/pkg" >> # shared library search paths >> Index: etc/rc.d/Makefile >> =================================================================== >> RCS file: /home/ncvs/src/etc/rc.d/Makefile,v >> retrieving revision 1.47 >> diff -u -r1.47 Makefile >> --- etc/rc.d/Makefile 16 Nov 2004 04:20:09 -0000 1.47 >> +++ etc/rc.d/Makefile 10 Jan 2005 00:55:40 -0000 >> @@ -26,7 +26,7 @@ >> nfslocking nfsserver nisdomain nsswitch ntpd ntpdate \ >> othermta \ >> pccard pcvt pf pflog \ >> - power_profile ppp-user pppoed preseedrandom pwcheck \ >> + power_profile ppp-user pppoed preparex11 preseedrandom pwcheck \ >> quota \ >> ramdisk ramdisk-own random rarpd rcconf.sh resolv root \ >> route6d routed routing rpcbind rtadvd rwho \ >> Index: etc/rc.d/cleartmp >> =================================================================== >> RCS file: /home/ncvs/src/etc/rc.d/cleartmp,v >> retrieving revision 1.11 >> diff -u -r1.11 cleartmp >> --- etc/rc.d/cleartmp 7 Oct 2004 13:55:25 -0000 1.11 >> +++ etc/rc.d/cleartmp 10 Jan 2005 01:00:08 -0000 >> @@ -6,7 +6,7 @@ >> >> # PROVIDE: cleartmp >> # REQUIRE: mountcritremote tmp >> -# BEFORE: DAEMON >> +# BEFORE: DAEMON preparex11 >> >> > I think you may take this better from your new script. rcNG also > support and REQUIRE/AFTER keyword. I think you must take preparex11 > _after_ cleartmp > > The only 'consumers' of this I know are xdm related scripts on > localpkg and gettys from init after > rc has finished. > >> >> . /etc/rc.subr >> >> @@ -30,10 +30,3 @@ >> >> load_rc_config $name >> run_rc_command "$1" >> - >> -# Remove X lock files, since they will prevent you from >> -# restarting X >> -# >> -rm -f /tmp/.X[0-9]-lock >> -rm -fr /tmp/.X11-unix >> -mkdir -m 1777 /tmp/.X11-unix >> Index: etc/rc.d/preparex11 >> =================================================================== >> RCS file: etc/rc.d/preparex11 >> diff -N etc/rc.d/preparex11 >> --- /dev/null 1 Jan 1970 00:00:00 -0000 >> +++ etc/rc.d/preparex11 10 Jan 2005 01:10:44 -0000 >> @@ -0,0 +1,27 @@ >> +#!/bin/sh >> +# >> +# $FreeBSD$ >> +# >> + >> +# PROVIDE: preparex11 >> >> > consider REQUIRE: mountall cleartmp > >> +# REQUIRE: mountall >> +# BEFORE: DAEMON >> >> > We have lost symtem flags > >> +# KEYWORD: FreeBSD NetBSD >> >> + >> +. /etc/rc.subr >> + >> +name="preparex11" >> +rcvar=`set_rcvar prepare_x11` >> +start_cmd="preparex11_start" >> +stop_cmd=":" >> + >> +preparex11_start() >> +{ >> + echo "Preparing /tmp for X11 applications." >> + rm -f /tmp/.X*-lock >> + rm -fr /tmp/.X11-unix /tmp/.font-unix /tmp/.ICE-unix >> + mkdir -m 1777 /tmp/.X11-unix /tmp/.font-unix /tmp/.ICE-unix >> +} >> + >> +load_rc_config $name >> >> > if you add the next auto default here, this same script will work > installed from ports. Install it with, 000. name prefix, so this is > take before gdm.sh or similar > > : ${prepare_x11_enable:="YES"} > >> +run_rc_command "$1" >> Index: share/man/man5/rc.conf.5 >> =================================================================== >> RCS file: /home/ncvs/src/share/man/man5/rc.conf.5,v >> retrieving revision 1.241 >> diff -u -r1.241 rc.conf.5 >> --- share/man/man5/rc.conf.5 5 Jan 2005 09:52:12 -0000 1.241 >> +++ share/man/man5/rc.conf.5 10 Jan 2005 01:25:36 -0000 >> @@ -2586,6 +2586,17 @@ >> to have >> .Pa /tmp >> cleaned at startup. >> +.It Va prepare_x11_enable >> +.Pq Vt bool >> +Set to >> +.Dq Li NO >> +to disable removing stale X server lockfiles and disable removing >> and recreating >> +.Pa /tmp/.ICE-unix , >> +.Pa /tmp/.X11-unix , >> +and >> +.Pa /tmp/.font-unix >> +at startup. May be a security issue if X11 applications are used >> with this >> +disabled. >> .It Va ldconfig_paths >> .Pq Vt str >> Set to the list of shared library paths to use with >> >> >> >> > > > -- > josemi > _______________________________________________ > freebsd-x11@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org" > > From owner-freebsd-x11@FreeBSD.ORG Mon Jan 10 11:03:20 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0174216A4EC for ; Mon, 10 Jan 2005 11:03:20 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA2B143D2F for ; Mon, 10 Jan 2005 11:03:19 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j0AB3JqF095638 for ; Mon, 10 Jan 2005 11:03:19 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j0AB3Ig3095632 for freebsd-x11@freebsd.org; Mon, 10 Jan 2005 11:03:18 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 10 Jan 2005 11:03:18 GMT Message-Id: <200501101103.j0AB3Ig3095632@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-x11@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 11:03:20 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- f [2001/03/07] ports/25576 x11 XFree86-4 port installs manual pages with o [2001/11/20] ports/32121 x11 XFree86-4-Server: xf86cfg 4.1.0 writes ba f [2004/07/02] ports/68599 x11 XFree86 in realloc(): error: allocation f o [2004/07/28] ports/69723 x11 4.10 update or install fails when X11 inc f [2004/08/07] ports/70139 x11 xorg-server 6.7: segfault reloading ddc m o [2004/08/11] ports/70317 x11 xvideo problems using XFree86-4.4.0 o [2004/11/22] ports/74265 x11 XFree86 Version 4.4.0 with KDE 3.1 freeze o [2004/12/06] ports/74757 x11 XFree86 4.4/Xorg 6.7.0 i810 problem with 8 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- s [2003/08/18] ports/55699 x11 [PATCH] making x11-servers/XFree86-4-Serv f [2003/11/15] ports/59297 x11 RADEON 7500 Warning message o [2004/05/11] ports/66511 x11 xdm xlogin*background color issue f [2004/06/29] ports/68476 x11 X -query myserver does not open an xsessi o [2004/09/14] ports/71724 x11 x11/XFree86-4-clients: luit does not reco o [2004/10/22] ports/73009 x11 5.3-RC1 ports refer to XF86Config - shoul o [2004/11/09] ports/73743 x11 XOrg/XFree xauth add/startx problem o [2004/11/16] ports/74000 x11 [PATCH] add xdm rc script to xorg-clients o [2004/11/16] ports/74003 x11 [PATCH] add xdm rc script to x11/XFree86- o [2004/11/21] ports/74190 x11 x11/XFree86-aoutlibs fix o [2004/12/12] ports/74981 x11 [PATCH] x11/xorg-clients: luit has synchr o [2004/12/30] ports/75652 x11 Ad a x11cleartmp.sh script to safe use X 12 problems total. From owner-freebsd-x11@FreeBSD.ORG Mon Jan 10 11:08:05 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D50216A4CE for ; Mon, 10 Jan 2005 11:08:05 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0652A43D5D for ; Mon, 10 Jan 2005 11:08:05 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j0AB84Jc002084 for ; Mon, 10 Jan 2005 11:08:04 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j0AB83sC002078 for x11@freebsd.org; Mon, 10 Jan 2005 11:08:03 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 10 Jan 2005 11:08:03 GMT Message-Id: <200501101108.j0AB83sC002078@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: x11@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 11:08:05 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/12/30] ports/75650 x11 [PATCH] x11/xorg-libraries: [SUMMARIZE CH o [2004/12/30] ports/75666 x11 add Matrox MGA Driver to xorg-server 2 problems total. From owner-freebsd-x11@FreeBSD.ORG Mon Jan 10 13:45:45 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED55C16A4CE for ; Mon, 10 Jan 2005 13:45:45 +0000 (GMT) Received: from mail.mdanderson.org (mail.mdanderson.org [143.111.251.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A8AB43D1F for ; Mon, 10 Jan 2005 13:45:45 +0000 (GMT) (envelope-from jonathan@fosburgh.org) Received: by jef-nt.mdacc.tmc.edu (Postfix, from userid 1001) id 8F9B58F4; Mon, 10 Jan 2005 07:45:39 -0600 (CST) From: Jonathan Fosburgh To: freebsd-x11@freebsd.org Date: Mon, 10 Jan 2005 07:45:31 -0600 User-Agent: KMail/1.7.2 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1539003.LWYtWdj4Il"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501100745.38490.jonathan@fosburgh.org> Subject: Radeon DRI problems after system upgrade X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 13:45:46 -0000 --nextPart1539003.LWYtWdj4Il Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I recently (this weekend) upgraded my aging P-III system to an AMD Athlon 6= 4=20 (still running the i386 version of FreeBSD) and DRI has stopped working. I= =20 am running a recent 5.3-STABLE with Xorg 6.8.1 and the current graphics/dri= =20 from ports. AGP is compiled into the kernel. The chipset is SiS 755. I=20 receive the following error now when drm0 loads: Jan 9 04:27:17 gw kernel: agp0: binding memory at bad offset 0 Jan 9 04:27:17 gw kernel: error: [drm:pid688:radeon_cp_init] *ERROR*=20 radeon_cp_init called without lock held Jan 9 04:27:17 gw kernel: error: [drm:pid688:radeon_unlock] *ERROR* Proces= s=20 688 using kernel context 0 =46rom postings to mailing lists, this indicates that AGP is not loaded, bu= t I=20 made sure to build it statically into the kernel when I first noticed the=20 problem. Here are some particulars: Jan 9 04:27:17 gw kernel: drm0: port=20 0xd000-0xd0ff mem 0xe8020000-0xe802ffff,0xe0000000-0xe7ffffff irq 16 at=20 device 0.0 on pci1 Jan 9 04:27:17 gw kernel: info: [drm] AGP at 0xd8000000 128MB Jan 9 04:27:17 gw kernel: info: [drm] Initialized radeon 1.11.0 20020828 o= n=20 minor 0 pciconf -lv reports the following for AGP: agp0@pci0:0:0: class=3D0x060000 card=3D0x18911019 chip=3D0x07551039 rev=3D= 0x01=20 hdr=3D0x00 vendor =3D 'Silicon Integrated Systems (SiS)' device =3D 'SiSM650? Host-to-PCI Bridge' class =3D bridge subclass =3D HOST-PCI and for drm0: drm0@pci1:0:0: class=3D0x030000 card=3D0x2081148c chip=3D0x51591002 rev=3D= 0x00=20 hdr=3D0x00 vendor =3D 'ATI Technologies Inc.' device =3D 'RV100 Radeon 7000 / Radeon VE' class =3D display subclass =3D VGA DRI used to work with this release of Xorg and the same -STABLE sources. F= rom=20 old syslogs: Dec 27 21:09:44 gw kernel: agp0: =20 mem 0xe4000000-0xe7ffffff at device 0.0 on pci0 Dec 27 21:10:00 gw kernel: drm0: port=20 0xd800-0xd8ff mem 0xd7000000-0xd700ffff,0xd8000000-0xdfffffff irq 11 at=20 device 0.0 on pci1 Dec 27 21:10:00 gw kernel: info: [drm] AGP at 0xe4000000 64MB Dec 27 21:10:00 gw kernel: info: [drm] Initialized radeon 1.11.0 20020828 o= n=20 minor 0 My only guess is that this has something to do with AGP support for this=20 chipset. Does anyone have a suggestion? =2D-=20 Jonathan Fosburgh AIX and Storage Administrator UT MD Anderson Cancer Center Houston, TX --nextPart1539003.LWYtWdj4Il Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBB4ocCqUvQmqp7omYRAr6/AKDGaOm1EdjMtiBl5krPay335WRy/wCgoQAS COVA9neW4kEIA81eGDD8ids= =dA1i -----END PGP SIGNATURE----- --nextPart1539003.LWYtWdj4Il-- From owner-freebsd-x11@FreeBSD.ORG Mon Jan 10 16:58:45 2005 Return-Path: Delivered-To: freebsd-x11@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2EF6C16A4CE; Mon, 10 Jan 2005 16:58:45 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF96943D48; Mon, 10 Jan 2005 16:58:44 +0000 (GMT) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j0AGwivE041686; Mon, 10 Jan 2005 16:58:44 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j0AGwidv041682; Mon, 10 Jan 2005 16:58:44 GMT (envelope-from linimon) Date: Mon, 10 Jan 2005 16:58:44 GMT From: Mark Linimon Message-Id: <200501101658.j0AGwidv041682@freefall.freebsd.org> To: linimon@FreeBSD.org, x11@FreeBSD.org, freebsd-x11@FreeBSD.org Subject: Re: ports/75650: [PATCH] x11/xorg-libraries: add suport for /tmp conformance before xorg use X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 16:58:45 -0000 Old Synopsis: [PATCH] x11/xorg-libraries: [SUMMARIZE CHANGES] New Synopsis: [PATCH] x11/xorg-libraries: add suport for /tmp conformance before xorg use Responsible-Changed-From-To: x11->freebsd-x11 Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jan 10 16:57:57 GMT 2005 Responsible-Changed-Why: Canonicalize assignment and fix Synopsis. http://www.freebsd.org/cgi/query-pr.cgi?pr=75650 From owner-freebsd-x11@FreeBSD.ORG Mon Jan 10 16:58:45 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2EF6C16A4CE; Mon, 10 Jan 2005 16:58:45 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF96943D48; Mon, 10 Jan 2005 16:58:44 +0000 (GMT) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j0AGwivE041686; Mon, 10 Jan 2005 16:58:44 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j0AGwidv041682; Mon, 10 Jan 2005 16:58:44 GMT (envelope-from linimon) Date: Mon, 10 Jan 2005 16:58:44 GMT From: Mark Linimon Message-Id: <200501101658.j0AGwidv041682@freefall.freebsd.org> To: linimon@FreeBSD.org, x11@FreeBSD.org, freebsd-x11@FreeBSD.org Subject: Re: ports/75650: [PATCH] x11/xorg-libraries: add suport for /tmp conformance before xorg use X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 16:58:45 -0000 Old Synopsis: [PATCH] x11/xorg-libraries: [SUMMARIZE CHANGES] New Synopsis: [PATCH] x11/xorg-libraries: add suport for /tmp conformance before xorg use Responsible-Changed-From-To: x11->freebsd-x11 Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jan 10 16:57:57 GMT 2005 Responsible-Changed-Why: Canonicalize assignment and fix Synopsis. http://www.freebsd.org/cgi/query-pr.cgi?pr=75650 From owner-freebsd-x11@FreeBSD.ORG Mon Jan 10 16:59:07 2005 Return-Path: Delivered-To: freebsd-x11@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B5E216A4CE; Mon, 10 Jan 2005 16:59:07 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB8E743D45; Mon, 10 Jan 2005 16:59:06 +0000 (GMT) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j0AGx6B5041731; Mon, 10 Jan 2005 16:59:06 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j0AGx628041727; Mon, 10 Jan 2005 16:59:06 GMT (envelope-from linimon) Date: Mon, 10 Jan 2005 16:59:06 GMT From: Mark Linimon Message-Id: <200501101659.j0AGx628041727@freefall.freebsd.org> To: linimon@FreeBSD.org, x11@FreeBSD.org, freebsd-x11@FreeBSD.org Subject: Re: ports/75666: add Matrox MGA Driver to xorg-server X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 16:59:07 -0000 Synopsis: add Matrox MGA Driver to xorg-server Responsible-Changed-From-To: x11->freebsd-x11 Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jan 10 16:58:55 GMT 2005 Responsible-Changed-Why: Canonicalize assignment. http://www.freebsd.org/cgi/query-pr.cgi?pr=75666 From owner-freebsd-x11@FreeBSD.ORG Mon Jan 10 16:59:07 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B5E216A4CE; Mon, 10 Jan 2005 16:59:07 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB8E743D45; Mon, 10 Jan 2005 16:59:06 +0000 (GMT) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j0AGx6B5041731; Mon, 10 Jan 2005 16:59:06 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j0AGx628041727; Mon, 10 Jan 2005 16:59:06 GMT (envelope-from linimon) Date: Mon, 10 Jan 2005 16:59:06 GMT From: Mark Linimon Message-Id: <200501101659.j0AGx628041727@freefall.freebsd.org> To: linimon@FreeBSD.org, x11@FreeBSD.org, freebsd-x11@FreeBSD.org Subject: Re: ports/75666: add Matrox MGA Driver to xorg-server X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 16:59:07 -0000 Synopsis: add Matrox MGA Driver to xorg-server Responsible-Changed-From-To: x11->freebsd-x11 Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jan 10 16:58:55 GMT 2005 Responsible-Changed-Why: Canonicalize assignment. http://www.freebsd.org/cgi/query-pr.cgi?pr=75666 From owner-freebsd-x11@FreeBSD.ORG Mon Jan 10 17:47:53 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B4C0116A4CE; Mon, 10 Jan 2005 17:47:53 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57F5143D54; Mon, 10 Jan 2005 17:47:53 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j0AHoLor017867; Mon, 10 Jan 2005 09:50:22 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j0AHoJ05017864; Mon, 10 Jan 2005 09:50:19 -0800 Date: Mon, 10 Jan 2005 09:50:19 -0800 From: Brooks Davis To: Jose M Rodriguez Message-ID: <20050110175019.GA15907@odin.ac.hmc.edu> References: <41DDC4F2.5090709@yahoo.com> <20050107003806.GA14003@odin.ac.hmc.edu> <41DE5242.4030606@redesjm.local> <20050107182024.GB30931@odin.ac.hmc.edu> <41E16B3C.30302@redesjm.local> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: <41E16B3C.30302@redesjm.local> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: Rob cc: freebsd-current cc: x11@freebsd.org Subject: Re: Xorg ICE vs. Xfce4 (4.2-RC3) needs fixing /etc/rc.d/cleartmp X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 17:47:53 -0000 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 09, 2005 at 06:34:52PM +0100, Jose M Rodriguez wrote: > Brooks Davis escribi=F3: >=20 > >On Fri, Jan 07, 2005 at 10:11:30AM +0100, Jose M Rodriguez wrote: > >=20 > > > >>Brooks Davis escribi=F3: > >> > >> =20 > >> > >>>Could you please try the following patch? It does the same thing, but > >>>gives the inode paranoid a way to disable the creation of these > >>>directories or only create the ones they need. > >>> > >>>-- Brooks > >>> > >>>Index: rc.d/cleartmp > >>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>RCS file: /usr/cvs/src/etc/rc.d/cleartmp,v > >>>retrieving revision 1.11 > >>>diff -u -p -r1.11 cleartmp > >>>--- rc.d/cleartmp 7 Oct 2004 13:55:25 -0000 1.11 > >>>+++ rc.d/cleartmp 7 Jan 2005 00:31:51 -0000 > >>>@@ -35,5 +35,7 @@ run_rc_command "$1" > >>># restarting X > >>># > >>>rm -f /tmp/.X[0-9]-lock > >>>-rm -fr /tmp/.X11-unix > >>>-mkdir -m 1777 /tmp/.X11-unix > >>>+if [ -n ${clear_tmp_xdirs} ]; then > >>>+ rm -fr ${clear_tmp_xdirs} > >>>+ mkdir -m 1777 ${clear_tmp_xdirs} > >>>+fi > >>>Index: defaults/rc.conf > >>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>RCS file: /usr/cvs/src/etc/defaults/rc.conf,v > >>>retrieving revision 1.235 > >>>diff -u -p -r1.235 rc.conf > >>>--- defaults/rc.conf 15 Dec 2004 12:39:28 -0000 1.235 > >>>+++ defaults/rc.conf 7 Jan 2005 00:30:49 -0000 > >>>@@ -443,6 +443,8 @@ linux_enable=3D"NO" # Linux binary compati > >>>svr4_enable=3D"NO" # SysVR4 emulation loaded at startup (or NO). > >>>osf1_enable=3D"NO" # Alpha OSF/1 emulation loaded at startup (or NO). > >>>clear_tmp_enable=3D"NO" # Clear /tmp at startup. > >>>+clear_tmp_xdirs=3D"/tmp/.X11-unix /tmp/.font-unix /tmp/.ICE-unix" > >>>+ # Directories needed by X11 > >>>ldconfig_insecure=3D"NO" # Set to YES to disable ldconfig security=20 > >>>checks > >>>ldconfig_paths=3D"/usr/lib/compat /usr/X11R6/lib /usr/local/lib=20 > >>>/usr/local/lib/compat/pkg" > >>> # shared library search paths > >>> > >>> > >>> > >>> =20 > >>> > >>I recall putting this in a conf PR, try a follow-up. > >> > >>But I think your patch is a little bit wrong > >> > >>I never like the way X11 is taken by /etc/rc.d/cleartmp. none must b= e=20 > >>do after the run_rc_command. > >> =20 > >> > > > >That's easy enough to fix. > > > >=20 > > > >>If we need do this from the base system (Thing that I doubt more and=20 > >>more), this must be implementing a new /etc/rc.d/clearx11tmp (this may= =20 > >>be do in the main /etc/rc.d/cleartmp, like in sendmail), with all the= =20 > >>bits: > >>clear_x11tmp_enable, clear_x11tmp_dirs, ... > >> > >>But I must point that: > >> > >>X11 is now mostly a ports thing, not a base system component. If this= =20 > >>can be take from ports (I send-pr this also), this must be the path to= =20 > >>the solution. I put a simple script from libs, but I can work and rcNG= =20 > >>enabled thing if prefered. > >> > >>This is not what x11 really needs. x11 only needs some like this: mkdi= r=20 > >>-p ... && chown root:wheel ... && chmod 01777 ... . this may be=20 > >>prefered by the x11 team. > >> > >>This can be taken both from base and ports without too much problem. = =20 > >>The only secondary effect of this I know is that you may polite /tmp=20 > >>entries twice, with is not a real pain to the whole boot process. > >> =20 > >> > > > >My worry with using your patch is that localpkg is run quite late in the > >startup process, well after X may have tried to start if xdm is run from > >/etc/ttys. If package startup scripts could run anywhere in the order, > >a script in the port would be obvious solution, but that's not the case. > > > You're molsty wrong. init launch gettys after rc has finished (and also= =20 > localpkg). You are correct. According to "The Design and Implementation of the FreeBSD Operating System" init does not spawn processes ttys until after /etc/rc exits sucessfully. Good luck getting your port commited, I'm done with this issue. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFB4sBaXY6L6fI4GtQRAopRAKCv9tX9Dc2Qa6R/ztD+roK+OjJMdACePg87 8UfuVHbxkY6/+k7mNyJTMnU= =ZdJP -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI-- From owner-freebsd-x11@FreeBSD.ORG Mon Jan 10 18:36:01 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 49A7116A4CE for ; Mon, 10 Jan 2005 18:36:01 +0000 (GMT) Received: from leguin.anholt.net (69-30-77-85.dq1sn.easystreet.com [69.30.77.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id E417843D2D for ; Mon, 10 Jan 2005 18:36:00 +0000 (GMT) (envelope-from eta@lclark.edu) Received: from leguin.anholt.net (localhost [127.0.0.1]) by leguin.anholt.net (8.13.1/8.13.1) with ESMTP id j0AIZv4I004203; Mon, 10 Jan 2005 10:35:57 -0800 (PST) (envelope-from eta@lclark.edu) Received: (from anholt@localhost) by leguin.anholt.net (8.13.1/8.13.1/Submit) id j0AIZu35004202; Mon, 10 Jan 2005 10:35:56 -0800 (PST) (envelope-from eta@lclark.edu) X-Authentication-Warning: leguin.anholt.net: anholt set sender to eta@lclark.edu using -f From: Eric Anholt To: Jose M Rodriguez In-Reply-To: <41E23F8F.4040701@redesjm.local> References: <1105321614.8452.54.camel@leguin> <41E23C58.10606@redesjm.local> <41E23F8F.4040701@redesjm.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Jan 2005 10:35:56 -0800 Message-Id: <1105382156.2497.6.camel@leguin> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 FreeBSD GNOME Team Port cc: x11@freebsd.org Subject: Re: x11 /tmp preparation rc.d script X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 18:36:01 -0000 On Mon, 2005-01-10 at 09:40 +0100, Jose M Rodriguez wrote: > Jose M Rodriguez escribi=F3: >=20 > > Eric Anholt escribi=F3: > > > >> Attached are my proposed patches to deal with the X11 ICE issue. To > >> review, it's required because having .ICE not owned by root is a > >> security issue, one that's been papered over with a printed warning an= d > >> sleep(5) in libICE for years, and has recently been changed into an > >> actual error by the X.Org folks. > >> > ... >=20 > As a latter think about this, consider take also periodic related fixes=20 > (We clear this directories by default) and try to get a OS_VERSION bump=20 > closest to this. I'm sorry, I'm not sure what exactly you're talking about here. Are you saying that /etc/periodic contains something that will wipe out X's files in /tmp? That would be rather broken. --=20 Eric Anholt eta@lclark.edu =20 http://people.freebsd.org/~anholt/ anholt@FreeBSD.org From owner-freebsd-x11@FreeBSD.ORG Mon Jan 10 19:03:58 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B380116A4CE; Mon, 10 Jan 2005 19:03:58 +0000 (GMT) Received: from niobe.ijs.si (mail.ijs.si [193.2.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id B29B343D45; Mon, 10 Jan 2005 19:03:57 +0000 (GMT) (envelope-from dejan.lesjak@ijs.si) Received: from localhost (localhost.ijs.si [127.0.0.1]) by niobe.ijs.si (Postfix) with ESMTP id 474FF1DD496; Mon, 10 Jan 2005 20:03:56 +0100 (CET) Received: from niobe.ijs.si ([127.0.0.1]) by localhost (niobe.ijs.si [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78372-02; Mon, 10 Jan 2005 20:03:38 +0100 (CET) Received: from metatron.ijs.si (metatron.ijs.si [193.2.4.152]) by niobe.ijs.si (Postfix) with ESMTP id 85C1D1DD4F5; Mon, 10 Jan 2005 20:03:37 +0100 (CET) Received: from idefix.ijs.si (idefix.ijs.si [193.2.4.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by metatron.ijs.si (Postfix) with ESMTP id 5D5131C0008A; Mon, 10 Jan 2005 20:03:36 +0100 (CET) From: Dejan Lesjak To: freebsd-x11@freebsd.org Date: Mon, 10 Jan 2005 20:03:34 +0100 User-Agent: KMail/1.7.2 References: <1105321614.8452.54.camel@leguin> <41E23F8F.4040701@redesjm.local> <1105382156.2497.6.camel@leguin> In-Reply-To: <1105382156.2497.6.camel@leguin> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200501102003.35785.dejan.lesjak@ijs.si> X-Virus-Scanned: amavisd-new at ijs.si cc: freebsd-rc@freebsd.org cc: x11@freebsd.org Subject: Re: x11 /tmp preparation rc.d script X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 19:03:58 -0000 [rc@ list CCed as this threads on their territory, the start of thread is=20 here:=20 http://lists.freebsd.org/pipermail/freebsd-x11/2005-January/001474.html] On Monday 10 of January 2005 19:35, Eric Anholt wrote: > On Mon, 2005-01-10 at 09:40 +0100, Jose M Rodriguez wrote: > > Jose M Rodriguez escribi=F3: > > > Eric Anholt escribi=F3: > > >> Attached are my proposed patches to deal with the X11 ICE issue. To > > >> review, it's required because having .ICE not owned by root is a > > >> security issue, one that's been papered over with a printed warning > > >> and sleep(5) in libICE for years, and has recently been changed into > > >> an actual error by the X.Org folks. > > > > ... > > > > As a latter think about this, consider take also periodic related fixes > > (We clear this directories by default) and try to get a OS_VERSION bump > > closest to this. > > I'm sorry, I'm not sure what exactly you're talking about here. Are you > saying that /etc/periodic contains something that will wipe out X's > files in /tmp? That would be rather broken. /etc/periodic/daily/110.clean-tmps cleans out empty directories that have n= ot=20 been modified in $daily_clean_tmps_days days. This ones should therefore be= =20 added to $daily_clean_tmps_ignore in /etc/defaults/periodic.conf, just to b= e=20 on the safe side. Other than that, I don't really know what would be the best way to handle=20 creation of this directories and haven't commented so far, but since I'm=20 already writing (mostly because I thought rc@ list should be CCed), here's = my=20 opinion FWIW: the simplest seems to be a patch from Pawel Worach at=20 http://lists.freebsd.org/mailman/htdig/freebsd-current/2004-November/042445= =2Ehtml The benefit of using this simple approach is that it is simple (of course := )=20 and furthermore it only adds two more directories to /tmp at startup as=20 oposed to adding a file in /etc/rc.d. The difference being one inode. But=20 then again, perhaps I don't see all the implications and this is too simple= =2E=20 Is there a real benefit in creating another rc.d script for doing this and= =20 adding a knob to turn creation of these directories off? Yes of course that would only solve things on -current and -stable, however= =20 there is already an UPDATING entry for this and we can always add a script = to=20 be installed from a port that would take care of transition period (probabl= y=20 as soon in dependency tree as possible, ie -libraries). Dejan From owner-freebsd-x11@FreeBSD.ORG Mon Jan 10 19:03:58 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B380116A4CE; Mon, 10 Jan 2005 19:03:58 +0000 (GMT) Received: from niobe.ijs.si (mail.ijs.si [193.2.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id B29B343D45; Mon, 10 Jan 2005 19:03:57 +0000 (GMT) (envelope-from dejan.lesjak@ijs.si) Received: from localhost (localhost.ijs.si [127.0.0.1]) by niobe.ijs.si (Postfix) with ESMTP id 474FF1DD496; Mon, 10 Jan 2005 20:03:56 +0100 (CET) Received: from niobe.ijs.si ([127.0.0.1]) by localhost (niobe.ijs.si [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78372-02; Mon, 10 Jan 2005 20:03:38 +0100 (CET) Received: from metatron.ijs.si (metatron.ijs.si [193.2.4.152]) by niobe.ijs.si (Postfix) with ESMTP id 85C1D1DD4F5; Mon, 10 Jan 2005 20:03:37 +0100 (CET) Received: from idefix.ijs.si (idefix.ijs.si [193.2.4.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by metatron.ijs.si (Postfix) with ESMTP id 5D5131C0008A; Mon, 10 Jan 2005 20:03:36 +0100 (CET) From: Dejan Lesjak To: freebsd-x11@freebsd.org Date: Mon, 10 Jan 2005 20:03:34 +0100 User-Agent: KMail/1.7.2 References: <1105321614.8452.54.camel@leguin> <41E23F8F.4040701@redesjm.local> <1105382156.2497.6.camel@leguin> In-Reply-To: <1105382156.2497.6.camel@leguin> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200501102003.35785.dejan.lesjak@ijs.si> X-Virus-Scanned: amavisd-new at ijs.si cc: freebsd-rc@freebsd.org cc: x11@freebsd.org Subject: Re: x11 /tmp preparation rc.d script X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 19:03:59 -0000 [rc@ list CCed as this threads on their territory, the start of thread is=20 here:=20 http://lists.freebsd.org/pipermail/freebsd-x11/2005-January/001474.html] On Monday 10 of January 2005 19:35, Eric Anholt wrote: > On Mon, 2005-01-10 at 09:40 +0100, Jose M Rodriguez wrote: > > Jose M Rodriguez escribi=F3: > > > Eric Anholt escribi=F3: > > >> Attached are my proposed patches to deal with the X11 ICE issue. To > > >> review, it's required because having .ICE not owned by root is a > > >> security issue, one that's been papered over with a printed warning > > >> and sleep(5) in libICE for years, and has recently been changed into > > >> an actual error by the X.Org folks. > > > > ... > > > > As a latter think about this, consider take also periodic related fixes > > (We clear this directories by default) and try to get a OS_VERSION bump > > closest to this. > > I'm sorry, I'm not sure what exactly you're talking about here. Are you > saying that /etc/periodic contains something that will wipe out X's > files in /tmp? That would be rather broken. /etc/periodic/daily/110.clean-tmps cleans out empty directories that have n= ot=20 been modified in $daily_clean_tmps_days days. This ones should therefore be= =20 added to $daily_clean_tmps_ignore in /etc/defaults/periodic.conf, just to b= e=20 on the safe side. Other than that, I don't really know what would be the best way to handle=20 creation of this directories and haven't commented so far, but since I'm=20 already writing (mostly because I thought rc@ list should be CCed), here's = my=20 opinion FWIW: the simplest seems to be a patch from Pawel Worach at=20 http://lists.freebsd.org/mailman/htdig/freebsd-current/2004-November/042445= =2Ehtml The benefit of using this simple approach is that it is simple (of course := )=20 and furthermore it only adds two more directories to /tmp at startup as=20 oposed to adding a file in /etc/rc.d. The difference being one inode. But=20 then again, perhaps I don't see all the implications and this is too simple= =2E=20 Is there a real benefit in creating another rc.d script for doing this and= =20 adding a knob to turn creation of these directories off? Yes of course that would only solve things on -current and -stable, however= =20 there is already an UPDATING entry for this and we can always add a script = to=20 be installed from a port that would take care of transition period (probabl= y=20 as soon in dependency tree as possible, ie -libraries). Dejan From owner-freebsd-x11@FreeBSD.ORG Mon Jan 10 19:17:51 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1DF816A4CE; Mon, 10 Jan 2005 19:17:51 +0000 (GMT) Received: from niobe.ijs.si (mail.ijs.si [193.2.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 503AF43D45; Mon, 10 Jan 2005 19:17:51 +0000 (GMT) (envelope-from dejan.lesjak@ijs.si) Received: from localhost (localhost.ijs.si [127.0.0.1]) by niobe.ijs.si (Postfix) with ESMTP id 809651DD4B2; Mon, 10 Jan 2005 20:17:50 +0100 (CET) Received: from niobe.ijs.si ([127.0.0.1]) by localhost (niobe.ijs.si [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81575-01; Mon, 10 Jan 2005 20:17:34 +0100 (CET) Received: from metatron.ijs.si (metatron.ijs.si [193.2.4.152]) by niobe.ijs.si (Postfix) with ESMTP id 8D0BB1DD4F5; Mon, 10 Jan 2005 20:14:01 +0100 (CET) Received: from idefix.ijs.si (idefix.ijs.si [193.2.4.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by metatron.ijs.si (Postfix) with ESMTP id 38E4C1C0008A; Mon, 10 Jan 2005 20:14:01 +0100 (CET) From: Dejan Lesjak To: freebsd-x11@freebsd.org Date: Mon, 10 Jan 2005 20:14:00 +0100 User-Agent: KMail/1.7.2 References: <20050109225147.GA76457@xor.obsecurity.org> In-Reply-To: <20050109225147.GA76457@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200501102014.00781.dejan.lesjak@ijs.si> X-Virus-Scanned: amavisd-new at ijs.si cc: x11@freebsd.org cc: Kris Kennaway Subject: Re: Xaw3d PORTVERSION bump X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 19:17:51 -0000 On Sunday 09 of January 2005 23:51, Kris Kennaway wrote: > Also, I think Xaw3d should have received a PORTVERSION bump because > the shlib version changed, and things that depended on it now do not > upgrade correctly with portupgrade because it doesn't know they should > be rebuilt. > > Kris Yes, I should have done this when adding a patch to bump XAWVER to bsd.port.mk. I also modified pkg-message to take value of XAWVER into account. Thanks for notifying. Dejan From owner-freebsd-x11@FreeBSD.ORG Mon Jan 10 19:17:51 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1DF816A4CE; Mon, 10 Jan 2005 19:17:51 +0000 (GMT) Received: from niobe.ijs.si (mail.ijs.si [193.2.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 503AF43D45; Mon, 10 Jan 2005 19:17:51 +0000 (GMT) (envelope-from dejan.lesjak@ijs.si) Received: from localhost (localhost.ijs.si [127.0.0.1]) by niobe.ijs.si (Postfix) with ESMTP id 809651DD4B2; Mon, 10 Jan 2005 20:17:50 +0100 (CET) Received: from niobe.ijs.si ([127.0.0.1]) by localhost (niobe.ijs.si [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81575-01; Mon, 10 Jan 2005 20:17:34 +0100 (CET) Received: from metatron.ijs.si (metatron.ijs.si [193.2.4.152]) by niobe.ijs.si (Postfix) with ESMTP id 8D0BB1DD4F5; Mon, 10 Jan 2005 20:14:01 +0100 (CET) Received: from idefix.ijs.si (idefix.ijs.si [193.2.4.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by metatron.ijs.si (Postfix) with ESMTP id 38E4C1C0008A; Mon, 10 Jan 2005 20:14:01 +0100 (CET) From: Dejan Lesjak To: freebsd-x11@freebsd.org Date: Mon, 10 Jan 2005 20:14:00 +0100 User-Agent: KMail/1.7.2 References: <20050109225147.GA76457@xor.obsecurity.org> In-Reply-To: <20050109225147.GA76457@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200501102014.00781.dejan.lesjak@ijs.si> X-Virus-Scanned: amavisd-new at ijs.si cc: x11@freebsd.org cc: Kris Kennaway Subject: Re: Xaw3d PORTVERSION bump X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 19:17:51 -0000 On Sunday 09 of January 2005 23:51, Kris Kennaway wrote: > Also, I think Xaw3d should have received a PORTVERSION bump because > the shlib version changed, and things that depended on it now do not > upgrade correctly with portupgrade because it doesn't know they should > be rebuilt. > > Kris Yes, I should have done this when adding a patch to bump XAWVER to bsd.port.mk. I also modified pkg-message to take value of XAWVER into account. Thanks for notifying. Dejan From owner-freebsd-x11@FreeBSD.ORG Mon Jan 10 19:35:39 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16AF516A4CE for ; Mon, 10 Jan 2005 19:35:39 +0000 (GMT) Received: from 212.106.238.57.adsl.jazztel.es (212.106.238.57.adsl.jazztel.es [212.106.238.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id C437E43D1D for ; Mon, 10 Jan 2005 19:35:37 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from [192.168.254.16] (orion.redesjm.local [192.168.254.16]) j0AJZX9I025022; Mon, 10 Jan 2005 20:35:34 +0100 (CET) (envelope-from freebsd@redesjm.local) Message-ID: <41E2D906.3030105@redesjm.local> Date: Mon, 10 Jan 2005 20:35:34 +0100 From: Jose M Rodriguez User-Agent: Mozilla Thunderbird 1.0 (X11/20050106) X-Accept-Language: es-es, es MIME-Version: 1.0 To: Eric Anholt References: <1105321614.8452.54.camel@leguin> <41E23C58.10606@redesjm.local> <41E23F8F.4040701@redesjm.local> <1105382156.2497.6.camel@leguin> In-Reply-To: <1105382156.2497.6.camel@leguin> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.29.0.5; VDF: 6.29.0.31; host: antares.redesjm.local) cc: x11@freebsd.org Subject: Re: x11 /tmp preparation rc.d script X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 19:35:39 -0000 Eric Anholt escribió: >On Mon, 2005-01-10 at 09:40 +0100, Jose M Rodriguez wrote: > > >>Jose M Rodriguez escribió: >> >> >> >>>Eric Anholt escribió: >>> >>> >>> >>>>Attached are my proposed patches to deal with the X11 ICE issue. To >>>>review, it's required because having .ICE not owned by root is a >>>>security issue, one that's been papered over with a printed warning and >>>>sleep(5) in libICE for years, and has recently been changed into an >>>>actual error by the X.Org folks. >>>> >>>> >>>> >>... >> >>As a latter think about this, consider take also periodic related fixes >>(We clear this directories by default) and try to get a OS_VERSION bump >>closest to this. >> >> > >I'm sorry, I'm not sure what exactly you're talking about here. Are you >saying that /etc/periodic contains something that will wipe out X's >files in /tmp? That would be rather broken. > > > take a look into /etc/periodic/daily/110.clean-tmps and /etc/defaults/periodic.conf. This is not me, I read this recently on lists/PRs, but the stock definition of daily_clean_tmps_ignore doesn't protect X11 directories, only X11 locks files. I don't think that this may be a real thread (I Have some Xterminal servers and I can't see /tmp/.ICE-unix vanished). It only may become a thread if files under /tmp/.ICE-unix are not accesed often, but I think that adding .X11-unix, .ICE-unix and .font-unix to daily_clean_tmps_ignore in the stock /etc/defaults/periodic may not hurt. -- josemi From owner-freebsd-x11@FreeBSD.ORG Mon Jan 10 19:51:08 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3250E16A4CE; Mon, 10 Jan 2005 19:51:08 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0233943D53; Mon, 10 Jan 2005 19:51:08 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j0AJreF1027525; Mon, 10 Jan 2005 11:53:40 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j0AJrevB027524; Mon, 10 Jan 2005 11:53:40 -0800 Date: Mon, 10 Jan 2005 11:53:40 -0800 From: Brooks Davis To: Eric Anholt Message-ID: <20050110195340.GC15907@odin.ac.hmc.edu> References: <1105321614.8452.54.camel@leguin> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1SQmhf2mF2YjsYvc" Content-Disposition: inline In-Reply-To: <1105321614.8452.54.camel@leguin> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: ports@freebsd.org cc: x11@freebsd.org Subject: Re: x11 /tmp preparation rc.d script X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 19:51:08 -0000 --1SQmhf2mF2YjsYvc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 09, 2005 at 05:46:54PM -0800, Eric Anholt wrote: > Attached are my proposed patches to deal with the X11 ICE issue. To > review, it's required because having .ICE not owned by root is a > security issue, one that's been papered over with a printed warning and > sleep(5) in libICE for years, and has recently been changed into an > actual error by the X.Org folks. >=20 > The question is whether to stick it in base or in ports: >=20 > In favor of ports: > - Seems like the proper place. Nothing happens for non-X11 users. > In favor of base: > - Would either need to make a separate port just for the script, or > keep the script in at least 3 separate ports, disregarding the > cleanup of servers which might make for more ports affected. > - From ports, it might get started too late in the boot process, or > not at all in some installations. It turns out that doing it in localpkg isn't a problem so we might want to go ahead and do it that way. One thing I've been wondering about is, why isn't startx/xdm doing this creation? They have the required privs and are garenteed not to get in a race (since it would be with them selves). -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --1SQmhf2mF2YjsYvc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFB4t1DXY6L6fI4GtQRAhPZAJ4nVJjL/SsPcSl4BUPZsjc0wBvm8gCdERT5 xvctx2Be+0fJrBdp4Hydm0s= =K3xm -----END PGP SIGNATURE----- --1SQmhf2mF2YjsYvc-- From owner-freebsd-x11@FreeBSD.ORG Mon Jan 10 19:52:42 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA0EA16A4CE; Mon, 10 Jan 2005 19:52:42 +0000 (GMT) Received: from 212.106.238.57.adsl.jazztel.es (212.106.238.57.adsl.jazztel.es [212.106.238.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id C360543D45; Mon, 10 Jan 2005 19:52:41 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from [192.168.254.16] (orion.redesjm.local [192.168.254.16]) j0AJqce1037229; Mon, 10 Jan 2005 20:52:38 +0100 (CET) (envelope-from freebsd@redesjm.local) Message-ID: <41E2DD07.6010607@redesjm.local> Date: Mon, 10 Jan 2005 20:52:39 +0100 From: Jose M Rodriguez User-Agent: Mozilla Thunderbird 1.0 (X11/20050106) X-Accept-Language: es-es, es MIME-Version: 1.0 To: Dejan Lesjak References: <1105321614.8452.54.camel@leguin> <41E23F8F.4040701@redesjm.local> <1105382156.2497.6.camel@leguin> <200501102003.35785.dejan.lesjak@ijs.si> In-Reply-To: <200501102003.35785.dejan.lesjak@ijs.si> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.29.0.5; VDF: 6.29.0.31; host: antares.redesjm.local) cc: freebsd-rc@freebsd.org cc: freebsd-x11@freebsd.org cc: x11@freebsd.org Subject: Re: x11 /tmp preparation rc.d script X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 19:52:43 -0000 Dejan Lesjak escribió: >[rc@ list CCed as this threads on their territory, the start of thread is >here: >http://lists.freebsd.org/pipermail/freebsd-x11/2005-January/001474.html] > >On Monday 10 of January 2005 19:35, Eric Anholt wrote: > > >>On Mon, 2005-01-10 at 09:40 +0100, Jose M Rodriguez wrote: >> >> >>>Jose M Rodriguez escribió: >>> >>> >>>>Eric Anholt escribió: >>>> >>>> >>>>>Attached are my proposed patches to deal with the X11 ICE issue. To >>>>>review, it's required because having .ICE not owned by root is a >>>>>security issue, one that's been papered over with a printed warning >>>>>and sleep(5) in libICE for years, and has recently been changed into >>>>>an actual error by the X.Org folks. >>>>> >>>>> >>>... >>> >>>As a latter think about this, consider take also periodic related fixes >>>(We clear this directories by default) and try to get a OS_VERSION bump >>>closest to this. >>> >>> >>I'm sorry, I'm not sure what exactly you're talking about here. Are you >>saying that /etc/periodic contains something that will wipe out X's >>files in /tmp? That would be rather broken. >> >> > >/etc/periodic/daily/110.clean-tmps cleans out empty directories that have not >been modified in $daily_clean_tmps_days days. This ones should therefore be >added to $daily_clean_tmps_ignore in /etc/defaults/periodic.conf, just to be >on the safe side. > >Other than that, I don't really know what would be the best way to handle >creation of this directories and haven't commented so far, but since I'm >already writing (mostly because I thought rc@ list should be CCed), here's my >opinion FWIW: the simplest seems to be a patch from Pawel Worach at >http://lists.freebsd.org/mailman/htdig/freebsd-current/2004-November/042445.html >The benefit of using this simple approach is that it is simple (of course :) >and furthermore it only adds two more directories to /tmp at startup as >oposed to adding a file in /etc/rc.d. The difference being one inode. But >then again, perhaps I don't see all the implications and this is too simple. > The only I know is that this breaks rcNG writing rules. This is a little more than style. I think that goin more modular can't hurt. >Is there a real benefit in creating another rc.d script for doing this and >adding a knob to turn creation of these directories off? > > Even more critical paths in the boot process are controlled in this manner. Why not? >Yes of course that would only solve things on -current and -stable, however > > This was allways the main problem of solve this 'only base'. >there is already an UPDATING entry for this and we can always add a script to >be installed from a port that would take care of transition period (probably >as soon in dependency tree as possible, ie -libraries). > > There are PRs on this. I think that latest rcNG script (with perhaps some tweaks to work from ports) installed from Xorg libraries will be the better first step. We may make this install_script conditional when we have the problem solved in RELENG_5 base (test OS_VERSION) and lost this when RELENG_4 life cycle was expired. >Dejan > > > > -- josemi From owner-freebsd-x11@FreeBSD.ORG Mon Jan 10 19:52:42 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA0EA16A4CE; Mon, 10 Jan 2005 19:52:42 +0000 (GMT) Received: from 212.106.238.57.adsl.jazztel.es (212.106.238.57.adsl.jazztel.es [212.106.238.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id C360543D45; Mon, 10 Jan 2005 19:52:41 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from [192.168.254.16] (orion.redesjm.local [192.168.254.16]) j0AJqce1037229; Mon, 10 Jan 2005 20:52:38 +0100 (CET) (envelope-from freebsd@redesjm.local) Message-ID: <41E2DD07.6010607@redesjm.local> Date: Mon, 10 Jan 2005 20:52:39 +0100 From: Jose M Rodriguez User-Agent: Mozilla Thunderbird 1.0 (X11/20050106) X-Accept-Language: es-es, es MIME-Version: 1.0 To: Dejan Lesjak References: <1105321614.8452.54.camel@leguin> <41E23F8F.4040701@redesjm.local> <1105382156.2497.6.camel@leguin> <200501102003.35785.dejan.lesjak@ijs.si> In-Reply-To: <200501102003.35785.dejan.lesjak@ijs.si> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.29.0.5; VDF: 6.29.0.31; host: antares.redesjm.local) cc: freebsd-rc@freebsd.org cc: freebsd-x11@freebsd.org cc: x11@freebsd.org Subject: Re: x11 /tmp preparation rc.d script X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 19:52:43 -0000 Dejan Lesjak escribió: >[rc@ list CCed as this threads on their territory, the start of thread is >here: >http://lists.freebsd.org/pipermail/freebsd-x11/2005-January/001474.html] > >On Monday 10 of January 2005 19:35, Eric Anholt wrote: > > >>On Mon, 2005-01-10 at 09:40 +0100, Jose M Rodriguez wrote: >> >> >>>Jose M Rodriguez escribió: >>> >>> >>>>Eric Anholt escribió: >>>> >>>> >>>>>Attached are my proposed patches to deal with the X11 ICE issue. To >>>>>review, it's required because having .ICE not owned by root is a >>>>>security issue, one that's been papered over with a printed warning >>>>>and sleep(5) in libICE for years, and has recently been changed into >>>>>an actual error by the X.Org folks. >>>>> >>>>> >>>... >>> >>>As a latter think about this, consider take also periodic related fixes >>>(We clear this directories by default) and try to get a OS_VERSION bump >>>closest to this. >>> >>> >>I'm sorry, I'm not sure what exactly you're talking about here. Are you >>saying that /etc/periodic contains something that will wipe out X's >>files in /tmp? That would be rather broken. >> >> > >/etc/periodic/daily/110.clean-tmps cleans out empty directories that have not >been modified in $daily_clean_tmps_days days. This ones should therefore be >added to $daily_clean_tmps_ignore in /etc/defaults/periodic.conf, just to be >on the safe side. > >Other than that, I don't really know what would be the best way to handle >creation of this directories and haven't commented so far, but since I'm >already writing (mostly because I thought rc@ list should be CCed), here's my >opinion FWIW: the simplest seems to be a patch from Pawel Worach at >http://lists.freebsd.org/mailman/htdig/freebsd-current/2004-November/042445.html >The benefit of using this simple approach is that it is simple (of course :) >and furthermore it only adds two more directories to /tmp at startup as >oposed to adding a file in /etc/rc.d. The difference being one inode. But >then again, perhaps I don't see all the implications and this is too simple. > The only I know is that this breaks rcNG writing rules. This is a little more than style. I think that goin more modular can't hurt. >Is there a real benefit in creating another rc.d script for doing this and >adding a knob to turn creation of these directories off? > > Even more critical paths in the boot process are controlled in this manner. Why not? >Yes of course that would only solve things on -current and -stable, however > > This was allways the main problem of solve this 'only base'. >there is already an UPDATING entry for this and we can always add a script to >be installed from a port that would take care of transition period (probably >as soon in dependency tree as possible, ie -libraries). > > There are PRs on this. I think that latest rcNG script (with perhaps some tweaks to work from ports) installed from Xorg libraries will be the better first step. We may make this install_script conditional when we have the problem solved in RELENG_5 base (test OS_VERSION) and lost this when RELENG_4 life cycle was expired. >Dejan > > > > -- josemi From owner-freebsd-x11@FreeBSD.ORG Mon Jan 10 22:37:09 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF03816A4CE; Mon, 10 Jan 2005 22:37:09 +0000 (GMT) Received: from leguin.anholt.net (69-30-77-85.dq1sn.easystreet.com [69.30.77.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DA5943D5D; Mon, 10 Jan 2005 22:37:09 +0000 (GMT) (envelope-from eta@lclark.edu) Received: from leguin.anholt.net (localhost [127.0.0.1]) by leguin.anholt.net (8.13.1/8.13.1) with ESMTP id j0AMb8XC001573; Mon, 10 Jan 2005 14:37:09 -0800 (PST) (envelope-from eta@lclark.edu) Received: (from anholt@localhost) by leguin.anholt.net (8.13.1/8.13.1/Submit) id j0AMb8YB001572; Mon, 10 Jan 2005 14:37:08 -0800 (PST) (envelope-from eta@lclark.edu) X-Authentication-Warning: leguin.anholt.net: anholt set sender to eta@lclark.edu using -f From: Eric Anholt To: freebsd-rc@FreeBSD.org, x11@FreeBSD.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 10 Jan 2005 14:37:08 -0800 Message-Id: <1105396628.866.12.camel@leguin> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 FreeBSD GNOME Team Port Subject: more libICE directory creation X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 22:37:09 -0000 (Just found out about this list from lesi@) After several rounds of proposed solutions to the X11 libICE problem, lesi suggested that we just put the .ICE-unix directory creation in cleartmp as was first proposed. Putting a script in ports would be doable, but adds more complications, and we've already got X11 pieces in cleartmp. While preparex11 taking over this job might be cleaner, it's easier to just add it to cleartmp and not make the directory creation optional (it's one inode, which we'd waste just the same by making a preparex11 script). Does anyone have an issue with this? I'm planning on doing it tomorrow unless there's an uproar. -- Eric Anholt eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org From owner-freebsd-x11@FreeBSD.ORG Mon Jan 10 22:43:37 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD85A16A4D6; Mon, 10 Jan 2005 22:43:37 +0000 (GMT) Received: from rooster.cisco.com (hen.cisco.com [64.102.19.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6125443D5E; Mon, 10 Jan 2005 22:43:37 +0000 (GMT) (envelope-from marcus@FreeBSD.org) Received: from [64.102.192.59] (dhcp-64-102-192-59.cisco.com [64.102.192.59]) by rooster.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id j0AMhXe01418; Mon, 10 Jan 2005 17:43:34 -0500 (EST) Message-ID: <41E3051B.4000904@FreeBSD.org> Date: Mon, 10 Jan 2005 17:43:39 -0500 From: Joe Marcus Clarke Organization: FreeBSD, Inc. User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Anholt References: <1105396628.866.12.camel@leguin> In-Reply-To: <1105396628.866.12.camel@leguin> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: x11@FreeBSD.org cc: freebsd-rc@FreeBSD.org Subject: Re: more libICE directory creation X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 22:43:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Anholt wrote: | (Just found out about this list from lesi@) | | After several rounds of proposed solutions to the X11 libICE problem, | lesi suggested that we just put the .ICE-unix directory creation in | cleartmp as was first proposed. Putting a script in ports would be | doable, but adds more complications, and we've already got X11 pieces in | cleartmp. While preparex11 taking over this job might be cleaner, it's | easier to just add it to cleartmp and not make the directory creation | optional (it's one inode, which we'd waste just the same by making a | preparex11 script). | | Does anyone have an issue with this? I'm planning on doing it tomorrow | unless there's an uproar. The only issue I have is that this doesn't help -RELEASE users (specifically 5.3-RELEASE users). I suppose this would work if we added it to the errata branch, but for pure -RELEASE users they still won't have a fix. Joe | - -- Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB4wUbb2iPiv4Uz4cRAmlKAJ9i1HIi+oVIWeyXGS3jxhtnISy66ACfYevi /qOid4nxjtqhjeuKPSOFiuU= =0mVL -----END PGP SIGNATURE----- From owner-freebsd-x11@FreeBSD.ORG Mon Jan 10 23:19:03 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2ED7616A4CE; Mon, 10 Jan 2005 23:19:03 +0000 (GMT) Received: from niobe.ijs.si (mail.ijs.si [193.2.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4370343D1D; Mon, 10 Jan 2005 23:19:02 +0000 (GMT) (envelope-from dejan.lesjak@ijs.si) Received: from localhost (localhost.ijs.si [127.0.0.1]) by niobe.ijs.si (Postfix) with ESMTP id 763501DD430; Tue, 11 Jan 2005 00:19:01 +0100 (CET) Received: from niobe.ijs.si ([127.0.0.1]) by localhost (niobe.ijs.si [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12250-01; Tue, 11 Jan 2005 00:18:49 +0100 (CET) Received: from metatron.ijs.si (metatron.ijs.si [193.2.4.152]) by niobe.ijs.si (Postfix) with ESMTP id 1FACC1DD45A; Tue, 11 Jan 2005 00:18:48 +0100 (CET) Received: from idefix.ijs.si (idefix.ijs.si [193.2.4.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by metatron.ijs.si (Postfix) with ESMTP id 94C5D1C0008A; Tue, 11 Jan 2005 00:18:48 +0100 (CET) From: Dejan Lesjak To: freebsd-x11@freebsd.org Date: Tue, 11 Jan 2005 00:18:47 +0100 User-Agent: KMail/1.7.2 References: <1105396628.866.12.camel@leguin> <41E3051B.4000904@FreeBSD.org> In-Reply-To: <41E3051B.4000904@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200501110018.47984.dejan.lesjak@ijs.si> X-Virus-Scanned: amavisd-new at ijs.si cc: freebsd-rc@freebsd.org cc: x11@freebsd.org Subject: Re: more libICE directory creation X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 23:19:03 -0000 On Monday 10 of January 2005 23:43, Joe Marcus Clarke wrote: > Eric Anholt wrote: > | (Just found out about this list from lesi@) > | > | After several rounds of proposed solutions to the X11 libICE problem, > | lesi suggested that we just put the .ICE-unix directory creation in > | cleartmp as was first proposed. Putting a script in ports would be > | doable, but adds more complications, and we've already got X11 pieces in > | cleartmp. While preparex11 taking over this job might be cleaner, it's > | easier to just add it to cleartmp and not make the directory creation > | optional (it's one inode, which we'd waste just the same by making a > | preparex11 script). > | > | Does anyone have an issue with this? I'm planning on doing it tomorrow > | unless there's an uproar. > > The only issue I have is that this doesn't help -RELEASE users > (specifically 5.3-RELEASE users). I suppose this would work if we added > it to the errata branch, but for pure -RELEASE users they still won't > have a fix. > > Joe A short rc script can be added to both -libraries ports (as they are the first in X11 dependencies so we get the script as soon as possible) as a temporary transition workaround. If the __FreeBSD_version is bumped at time when cleartmp is updated, we can install it based on that. And by short I mean something like this: /usr/X11R6/etc/rc.d/000.ICEtmp.sh: -------------------------------------------------------------------------- #!/bin/sh rm -fr /tmp/.ICE-unix mkdir -m 1777 /tmp/.ICE-unix -------------------------------------------------------------------------- Hm, I don't know if that would be OK, but given the shortness of this and that the versions of X.Org/XFree86 in last releases are not so strict about this, this could be put into UPDATING and avoid putting two scripts in ports, but I don't know if this is acceptable. Dejan From owner-freebsd-x11@FreeBSD.ORG Mon Jan 10 23:19:03 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2ED7616A4CE; Mon, 10 Jan 2005 23:19:03 +0000 (GMT) Received: from niobe.ijs.si (mail.ijs.si [193.2.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4370343D1D; Mon, 10 Jan 2005 23:19:02 +0000 (GMT) (envelope-from dejan.lesjak@ijs.si) Received: from localhost (localhost.ijs.si [127.0.0.1]) by niobe.ijs.si (Postfix) with ESMTP id 763501DD430; Tue, 11 Jan 2005 00:19:01 +0100 (CET) Received: from niobe.ijs.si ([127.0.0.1]) by localhost (niobe.ijs.si [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12250-01; Tue, 11 Jan 2005 00:18:49 +0100 (CET) Received: from metatron.ijs.si (metatron.ijs.si [193.2.4.152]) by niobe.ijs.si (Postfix) with ESMTP id 1FACC1DD45A; Tue, 11 Jan 2005 00:18:48 +0100 (CET) Received: from idefix.ijs.si (idefix.ijs.si [193.2.4.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by metatron.ijs.si (Postfix) with ESMTP id 94C5D1C0008A; Tue, 11 Jan 2005 00:18:48 +0100 (CET) From: Dejan Lesjak To: freebsd-x11@freebsd.org Date: Tue, 11 Jan 2005 00:18:47 +0100 User-Agent: KMail/1.7.2 References: <1105396628.866.12.camel@leguin> <41E3051B.4000904@FreeBSD.org> In-Reply-To: <41E3051B.4000904@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200501110018.47984.dejan.lesjak@ijs.si> X-Virus-Scanned: amavisd-new at ijs.si cc: freebsd-rc@freebsd.org cc: x11@freebsd.org Subject: Re: more libICE directory creation X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 23:19:03 -0000 On Monday 10 of January 2005 23:43, Joe Marcus Clarke wrote: > Eric Anholt wrote: > | (Just found out about this list from lesi@) > | > | After several rounds of proposed solutions to the X11 libICE problem, > | lesi suggested that we just put the .ICE-unix directory creation in > | cleartmp as was first proposed. Putting a script in ports would be > | doable, but adds more complications, and we've already got X11 pieces in > | cleartmp. While preparex11 taking over this job might be cleaner, it's > | easier to just add it to cleartmp and not make the directory creation > | optional (it's one inode, which we'd waste just the same by making a > | preparex11 script). > | > | Does anyone have an issue with this? I'm planning on doing it tomorrow > | unless there's an uproar. > > The only issue I have is that this doesn't help -RELEASE users > (specifically 5.3-RELEASE users). I suppose this would work if we added > it to the errata branch, but for pure -RELEASE users they still won't > have a fix. > > Joe A short rc script can be added to both -libraries ports (as they are the first in X11 dependencies so we get the script as soon as possible) as a temporary transition workaround. If the __FreeBSD_version is bumped at time when cleartmp is updated, we can install it based on that. And by short I mean something like this: /usr/X11R6/etc/rc.d/000.ICEtmp.sh: -------------------------------------------------------------------------- #!/bin/sh rm -fr /tmp/.ICE-unix mkdir -m 1777 /tmp/.ICE-unix -------------------------------------------------------------------------- Hm, I don't know if that would be OK, but given the shortness of this and that the versions of X.Org/XFree86 in last releases are not so strict about this, this could be put into UPDATING and avoid putting two scripts in ports, but I don't know if this is acceptable. Dejan From owner-freebsd-x11@FreeBSD.ORG Tue Jan 11 00:30:09 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C9D2916A4CE; Tue, 11 Jan 2005 00:30:09 +0000 (GMT) Received: from niobe.ijs.si (mail.ijs.si [193.2.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED20043D1F; Tue, 11 Jan 2005 00:30:08 +0000 (GMT) (envelope-from dejan.lesjak@ijs.si) Received: from localhost (localhost.ijs.si [127.0.0.1]) by niobe.ijs.si (Postfix) with ESMTP id 0E2F41DD4BE; Tue, 11 Jan 2005 01:30:08 +0100 (CET) Received: from niobe.ijs.si ([127.0.0.1]) by localhost (niobe.ijs.si [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19049-05; Tue, 11 Jan 2005 01:29:28 +0100 (CET) Received: from metatron.ijs.si (metatron.ijs.si [193.2.4.152]) by niobe.ijs.si (Postfix) with ESMTP id 41F3E1DD567; Tue, 11 Jan 2005 01:29:24 +0100 (CET) Received: from idefix.ijs.si (idefix.ijs.si [193.2.4.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by metatron.ijs.si (Postfix) with ESMTP id 010291C0008A; Tue, 11 Jan 2005 01:29:21 +0100 (CET) From: Dejan Lesjak To: freebsd-x11@freebsd.org Date: Tue, 11 Jan 2005 01:29:20 +0100 User-Agent: KMail/1.7.2 References: <1105321614.8452.54.camel@leguin> <20050110195340.GC15907@odin.ac.hmc.edu> In-Reply-To: <20050110195340.GC15907@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200501110129.21281.dejan.lesjak@ijs.si> X-Virus-Scanned: amavisd-new at ijs.si cc: ports@freebsd.org cc: x11@freebsd.org Subject: Re: x11 /tmp preparation rc.d script X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 00:30:09 -0000 On Monday 10 of January 2005 20:53, Brooks Davis wrote: > On Sun, Jan 09, 2005 at 05:46:54PM -0800, Eric Anholt wrote: > > Attached are my proposed patches to deal with the X11 ICE issue. To > > review, it's required because having .ICE not owned by root is a > > security issue, one that's been papered over with a printed warning and > > sleep(5) in libICE for years, and has recently been changed into an > > actual error by the X.Org folks. > > > > The question is whether to stick it in base or in ports: > > > > In favor of ports: > > - Seems like the proper place. Nothing happens for non-X11 users. > > In favor of base: > > - Would either need to make a separate port just for the script, or > > keep the script in at least 3 separate ports, disregarding the > > cleanup of servers which might make for more ports affected. > > - From ports, it might get started too late in the boot process, or > > not at all in some installations. > > It turns out that doing it in localpkg isn't a problem so we might want > to go ahead and do it that way. > > One thing I've been wondering about is, why isn't startx/xdm doing > this creation? They have the required privs and are garenteed not to > get in a race (since it would be with them selves). > > -- Brooks Because clients need ICE, not the server - if you run an X app on a remote box that doesn't have X server running and connects to X server on local box, the ICE directory that is used is on remote machine - where the client is. So startx/xdm creating it wouldn't help. Dejan From owner-freebsd-x11@FreeBSD.ORG Tue Jan 11 00:30:09 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C9D2916A4CE; Tue, 11 Jan 2005 00:30:09 +0000 (GMT) Received: from niobe.ijs.si (mail.ijs.si [193.2.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED20043D1F; Tue, 11 Jan 2005 00:30:08 +0000 (GMT) (envelope-from dejan.lesjak@ijs.si) Received: from localhost (localhost.ijs.si [127.0.0.1]) by niobe.ijs.si (Postfix) with ESMTP id 0E2F41DD4BE; Tue, 11 Jan 2005 01:30:08 +0100 (CET) Received: from niobe.ijs.si ([127.0.0.1]) by localhost (niobe.ijs.si [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19049-05; Tue, 11 Jan 2005 01:29:28 +0100 (CET) Received: from metatron.ijs.si (metatron.ijs.si [193.2.4.152]) by niobe.ijs.si (Postfix) with ESMTP id 41F3E1DD567; Tue, 11 Jan 2005 01:29:24 +0100 (CET) Received: from idefix.ijs.si (idefix.ijs.si [193.2.4.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by metatron.ijs.si (Postfix) with ESMTP id 010291C0008A; Tue, 11 Jan 2005 01:29:21 +0100 (CET) From: Dejan Lesjak To: freebsd-x11@freebsd.org Date: Tue, 11 Jan 2005 01:29:20 +0100 User-Agent: KMail/1.7.2 References: <1105321614.8452.54.camel@leguin> <20050110195340.GC15907@odin.ac.hmc.edu> In-Reply-To: <20050110195340.GC15907@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200501110129.21281.dejan.lesjak@ijs.si> X-Virus-Scanned: amavisd-new at ijs.si cc: ports@freebsd.org cc: x11@freebsd.org Subject: Re: x11 /tmp preparation rc.d script X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 00:30:10 -0000 On Monday 10 of January 2005 20:53, Brooks Davis wrote: > On Sun, Jan 09, 2005 at 05:46:54PM -0800, Eric Anholt wrote: > > Attached are my proposed patches to deal with the X11 ICE issue. To > > review, it's required because having .ICE not owned by root is a > > security issue, one that's been papered over with a printed warning and > > sleep(5) in libICE for years, and has recently been changed into an > > actual error by the X.Org folks. > > > > The question is whether to stick it in base or in ports: > > > > In favor of ports: > > - Seems like the proper place. Nothing happens for non-X11 users. > > In favor of base: > > - Would either need to make a separate port just for the script, or > > keep the script in at least 3 separate ports, disregarding the > > cleanup of servers which might make for more ports affected. > > - From ports, it might get started too late in the boot process, or > > not at all in some installations. > > It turns out that doing it in localpkg isn't a problem so we might want > to go ahead and do it that way. > > One thing I've been wondering about is, why isn't startx/xdm doing > this creation? They have the required privs and are garenteed not to > get in a race (since it would be with them selves). > > -- Brooks Because clients need ICE, not the server - if you run an X app on a remote box that doesn't have X server running and connects to X server on local box, the ICE directory that is used is on remote machine - where the client is. So startx/xdm creating it wouldn't help. Dejan From owner-freebsd-x11@FreeBSD.ORG Tue Jan 11 13:35:00 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA13B16A4CE for ; Tue, 11 Jan 2005 13:35:00 +0000 (GMT) Received: from smtp.itknowledge.ch (static-195-073.catv.glattnet.ch [80.242.195.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6899043D1F for ; Tue, 11 Jan 2005 13:34:58 +0000 (GMT) (envelope-from black@black.ch) Received: from mail.itknowledge.ch (Not Verified[10.0.1.100]) by smtp.itknowledge.ch with NetIQ MailMarshal (v6,0,3,8) id ; Tue, 11 Jan 2005 14:34:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 11 Jan 2005 14:35:57 +0100 Message-ID: <58BFB7CE61460E48BC3142FF352ECD2C0C0503@srv100.itknowledge.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: XFree86 / Xorg and ATI Driver on a Sony Vaio C1VE thread-index: AcT34ntqZ+BlfbXeQbSB0oUWv9Fbvg== From: "Ronny Fischer" To: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: XFree86 / Xorg and ATI Driver on a Sony Vaio C1VE X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 13:35:00 -0000 Hello @ FreeBSD I have a long week behind me, because I had try to get Xorg or XFree86 on= =20my Sony Vaio C1VE running. (Specs are here : http://reviews.zdnet.co.uk/hardware/notebooks/0,39023984,10000247,00.htm = ) The bad thing on this Laptop is the Screen Resolution of 1024x480. ATI Driver is running with 1024x480 but only with 8 Bit Colour. VESA Driver is running with 640x480 with 16 or 24 Bit Colour. I see also many other people in the WWW with the same problem.=20 With older Releases of FreeBSD or XFree86 it was no problem on this Lapto= p. I have try so many things that I really not know where to search also or = where to get help... Do you have any idea what I could do to get more then 8 Bit Colour with 1= 024x480 ? Thanx a lot,=20 HAVE FUN and=20 with my best regardz ronny ######################################################################## This e-mail message has been scanned for Viruses and Content and cleared = by NetIQ MailMarshal, the e-mail content security solution ######################################################################## From owner-freebsd-x11@FreeBSD.ORG Wed Jan 12 00:38:23 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA1C216A4CE; Wed, 12 Jan 2005 00:38:22 +0000 (GMT) Received: from mail.monkeytower.net (mail.monkeytower.net [195.49.173.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A03A43D53; Wed, 12 Jan 2005 00:38:22 +0000 (GMT) (envelope-from root@mail.monkeytower.net) Received: from root by mail.monkeytower.net with local Exim id 1CoWZ7-0009uQ-4l; Wed, 12 Jan 2005 01:40:49 +0100 Received: from mx2.freebsd.org ([216.136.204.119]) by mail.monkeytower.net with esmtp Exim id 1Co5dT-000Bmu-KR for mailinglists@suntsu.org; Mon, 10 Jan 2005 20:55:32 +0100 Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 9781655D54; Mon, 10 Jan 2005 19:51:15 +0000 (GMT) (envelope-from owner-freebsd-ports@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 2F4B716A4D8; Mon, 10 Jan 2005 19:51:13 +0000 (GMT) Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3250E16A4CE; Mon, 10 Jan 2005 19:51:08 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0233943D53; Mon, 10 Jan 2005 19:51:08 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j0AJreF1027525; Mon, 10 Jan 2005 11:53:40 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j0AJrevB027524; Mon, 10 Jan 2005 11:53:40 -0800 Date: Mon, 10 Jan 2005 11:53:40 -0800 From: Brooks Davis To: Eric Anholt Message-ID: <20050110195340.GC15907@odin.ac.hmc.edu> References: <1105321614.8452.54.camel@leguin> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1SQmhf2mF2YjsYvc" Content-Disposition: inline In-Reply-To: <1105321614.8452.54.camel@leguin> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-ports@freebsd.org Errors-To: owner-freebsd-ports@freebsd.org X-MailScanner-Information: contact information at http://www.monkeytower.net X-MailScanner: Found to be clean X-MailScanner-From: root@mail.monkeytower.net cc: ports@freebsd.org cc: x11@freebsd.org Subject: Re: x11 /tmp preparation rc.d script X-BeenThere: freebsd-x11@freebsd.org List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 00:38:23 -0000 --1SQmhf2mF2YjsYvc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 09, 2005 at 05:46:54PM -0800, Eric Anholt wrote: > Attached are my proposed patches to deal with the X11 ICE issue. To > review, it's required because having .ICE not owned by root is a > security issue, one that's been papered over with a printed warning and > sleep(5) in libICE for years, and has recently been changed into an > actual error by the X.Org folks. >=20 > The question is whether to stick it in base or in ports: >=20 > In favor of ports: > - Seems like the proper place. Nothing happens for non-X11 users. > In favor of base: > - Would either need to make a separate port just for the script, or > keep the script in at least 3 separate ports, disregarding the > cleanup of servers which might make for more ports affected. > - From ports, it might get started too late in the boot process, or > not at all in some installations. It turns out that doing it in localpkg isn't a problem so we might want to go ahead and do it that way. One thing I've been wondering about is, why isn't startx/xdm doing this creation? They have the required privs and are garenteed not to get in a race (since it would be with them selves). -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --1SQmhf2mF2YjsYvc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFB4t1DXY6L6fI4GtQRAhPZAJ4nVJjL/SsPcSl4BUPZsjc0wBvm8gCdERT5 xvctx2Be+0fJrBdp4Hydm0s= =K3xm -----END PGP SIGNATURE----- --1SQmhf2mF2YjsYvc-- From owner-freebsd-x11@FreeBSD.ORG Wed Jan 12 05:22:52 2005 Return-Path: Delivered-To: freebsd-x11@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0311516A4CE; Wed, 12 Jan 2005 05:22:52 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFEF643D4C; Wed, 12 Jan 2005 05:22:51 +0000 (GMT) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j0C5MpaE054132; Wed, 12 Jan 2005 05:22:51 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j0C5Mppl054127; Wed, 12 Jan 2005 05:22:51 GMT (envelope-from linimon) Date: Wed, 12 Jan 2005 05:22:51 GMT From: Mark Linimon Message-Id: <200501120522.j0C5Mppl054127@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-ports-bugs@FreeBSD.org, freebsd-x11@FreeBSD.org Subject: Re: ports/76115: xorg-libraries-6.8.1: apps crashing on large images (BadAlloc) X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 05:22:52 -0000 Synopsis: xorg-libraries-6.8.1: apps crashing on large images (BadAlloc) Responsible-Changed-From-To: freebsd-ports-bugs->freebsd-x11 Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jan 12 05:22:41 GMT 2005 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=76115 From owner-freebsd-x11@FreeBSD.ORG Wed Jan 12 17:10:08 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A7F816A4CE; Wed, 12 Jan 2005 17:10:08 +0000 (GMT) Received: from niobe.ijs.si (mail.ijs.si [193.2.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD8B143D31; Wed, 12 Jan 2005 17:10:06 +0000 (GMT) (envelope-from dejan.lesjak@ijs.si) Received: from localhost (localhost.ijs.si [127.0.0.1]) by niobe.ijs.si (Postfix) with ESMTP id 70F6D1DD58B; Wed, 12 Jan 2005 18:10:05 +0100 (CET) Received: from niobe.ijs.si ([127.0.0.1]) by localhost (niobe.ijs.si [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79118-12; Wed, 12 Jan 2005 18:09:48 +0100 (CET) Received: from metatron.ijs.si (metatron.ijs.si [193.2.4.152]) by niobe.ijs.si (Postfix) with ESMTP id D46961DD476; Wed, 12 Jan 2005 18:09:47 +0100 (CET) Received: from idefix.ijs.si (idefix.ijs.si [193.2.4.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by metatron.ijs.si (Postfix) with ESMTP id EC7631C0071F; Wed, 12 Jan 2005 18:09:46 +0100 (CET) From: Dejan Lesjak To: Jose M Rodriguez Date: Wed, 12 Jan 2005 18:09:45 +0100 User-Agent: KMail/1.7.2 References: <1105321614.8452.54.camel@leguin> <200501102003.35785.dejan.lesjak@ijs.si> <41E2DD07.6010607@redesjm.local> In-Reply-To: <41E2DD07.6010607@redesjm.local> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200501121809.46129.dejan.lesjak@ijs.si> X-Virus-Scanned: amavisd-new at ijs.si cc: freebsd-rc@freebsd.org cc: freebsd-x11@freebsd.org cc: x11@freebsd.org Subject: Re: x11 /tmp preparation rc.d script X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 17:10:08 -0000 On Monday 10 of January 2005 20:52, Jose M Rodriguez wrote: > Dejan Lesjak escribi=F3: > >Other than that, I don't really know what would be the best way to handle > >creation of this directories and haven't commented so far, but since I'm > >already writing (mostly because I thought rc@ list should be CCed), here= 's > > my opinion FWIW: the simplest seems to be a patch from Pawel Worach at > > http://lists.freebsd.org/mailman/htdig/freebsd-current/2004-November/04= 24 > >45.html The benefit of using this simple approach is that it is simple (= of > > course :) and furthermore it only adds two more directories to /tmp at > > startup as oposed to adding a file in /etc/rc.d. The difference being o= ne > > inode. But then again, perhaps I don't see all the implications and this > > is too simple. > > The only I know is that this breaks rcNG writing rules. This is a > little more than style. I think that goin more modular can't hurt. Well it is certainly an exception to how rcNG scripts are otherwise written= ,=20 but I don't see this as a bad thing. Creation of /tmp/.X11-unix and removal= =20 of X lock file is already there as that seems the right place to do that.=20 Because of this it also seems natural (to me at least) to just add creation= =20 of another dir there. I believe that having this in this script makes thing= s=20 done at the right time - if one has configured to have /tmp directory clean= ed=20 after boot, then things that should be recreated are recreated right after= =20 that; if no other explicitly ordered cleaning up is done, these directories= =20 (and a lock file) are still "cleaned" away and recreated with side effect o= f=20 having the right permissions. I'm not opposed of going modular, it just see= ms=20 that going modular for the sake of one directory is a bit of an overkill. > >Is there a real benefit in creating another rc.d script for doing this a= nd > >adding a knob to turn creation of these directories off? > > Even more critical paths in the boot process are controlled in this > manner. Why not? As I said, I'm not opposed of doing it in this manner, I just don't see the= =20 real need to create several additional scripts instead of changing two line= s=20 in existing one that already takes care of cleaning (and preparing) /tmp=20 directory. > >Yes of course that would only solve things on -current and -stable, > > however > > This was allways the main problem of solve this 'only base'. > > >there is already an UPDATING entry for this and we can always add a scri= pt > > to be installed from a port that would take care of transition period > > (probably as soon in dependency tree as possible, ie -libraries). > > There are PRs on this. I think that latest rcNG script (with perhaps > some tweaks to work from ports) installed from Xorg libraries will be > the better first step. We may make this install_script conditional when > we have the problem solved in RELENG_5 base (test OS_VERSION) and lost > this when RELENG_4 life cycle was expired. I'm aware of the PRs on this, I wanted to voice my opinion on the particula= r=20 problem of creating a directory /tmp/.ICE-unix with right permissions. Allow me to ramble a bit more on these: If we go to "modular" way as you pu= t=20 it, the we would have to add a script to create ICE-unix directory to, say,= =20 =2Dlibraries ports and a script to remove lock file and X11-unix to -server= =20 ports (more than two of them), while being careful not to let different=20 =2Dserver ports (as in server and nestserver...) step onto each others toes= =2E Or=20 we could make additional port to only install one rc script. This is=20 certainly doable and would of course be more or less modular and could even= =20 have knobs so one could choose if directories should be created/removed and= =20 if lock file should be created/removed. I can't help but to think that this= =20 would be using a bit tooo enormous hammer, that's why I still think a simpl= e=20 solution proposed by Pawel Worach would be enough here. Dejan From owner-freebsd-x11@FreeBSD.ORG Wed Jan 12 17:10:08 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A7F816A4CE; Wed, 12 Jan 2005 17:10:08 +0000 (GMT) Received: from niobe.ijs.si (mail.ijs.si [193.2.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD8B143D31; Wed, 12 Jan 2005 17:10:06 +0000 (GMT) (envelope-from dejan.lesjak@ijs.si) Received: from localhost (localhost.ijs.si [127.0.0.1]) by niobe.ijs.si (Postfix) with ESMTP id 70F6D1DD58B; Wed, 12 Jan 2005 18:10:05 +0100 (CET) Received: from niobe.ijs.si ([127.0.0.1]) by localhost (niobe.ijs.si [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79118-12; Wed, 12 Jan 2005 18:09:48 +0100 (CET) Received: from metatron.ijs.si (metatron.ijs.si [193.2.4.152]) by niobe.ijs.si (Postfix) with ESMTP id D46961DD476; Wed, 12 Jan 2005 18:09:47 +0100 (CET) Received: from idefix.ijs.si (idefix.ijs.si [193.2.4.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by metatron.ijs.si (Postfix) with ESMTP id EC7631C0071F; Wed, 12 Jan 2005 18:09:46 +0100 (CET) From: Dejan Lesjak To: Jose M Rodriguez Date: Wed, 12 Jan 2005 18:09:45 +0100 User-Agent: KMail/1.7.2 References: <1105321614.8452.54.camel@leguin> <200501102003.35785.dejan.lesjak@ijs.si> <41E2DD07.6010607@redesjm.local> In-Reply-To: <41E2DD07.6010607@redesjm.local> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200501121809.46129.dejan.lesjak@ijs.si> X-Virus-Scanned: amavisd-new at ijs.si cc: freebsd-rc@freebsd.org cc: freebsd-x11@freebsd.org cc: x11@freebsd.org Subject: Re: x11 /tmp preparation rc.d script X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 17:10:08 -0000 On Monday 10 of January 2005 20:52, Jose M Rodriguez wrote: > Dejan Lesjak escribi=F3: > >Other than that, I don't really know what would be the best way to handle > >creation of this directories and haven't commented so far, but since I'm > >already writing (mostly because I thought rc@ list should be CCed), here= 's > > my opinion FWIW: the simplest seems to be a patch from Pawel Worach at > > http://lists.freebsd.org/mailman/htdig/freebsd-current/2004-November/04= 24 > >45.html The benefit of using this simple approach is that it is simple (= of > > course :) and furthermore it only adds two more directories to /tmp at > > startup as oposed to adding a file in /etc/rc.d. The difference being o= ne > > inode. But then again, perhaps I don't see all the implications and this > > is too simple. > > The only I know is that this breaks rcNG writing rules. This is a > little more than style. I think that goin more modular can't hurt. Well it is certainly an exception to how rcNG scripts are otherwise written= ,=20 but I don't see this as a bad thing. Creation of /tmp/.X11-unix and removal= =20 of X lock file is already there as that seems the right place to do that.=20 Because of this it also seems natural (to me at least) to just add creation= =20 of another dir there. I believe that having this in this script makes thing= s=20 done at the right time - if one has configured to have /tmp directory clean= ed=20 after boot, then things that should be recreated are recreated right after= =20 that; if no other explicitly ordered cleaning up is done, these directories= =20 (and a lock file) are still "cleaned" away and recreated with side effect o= f=20 having the right permissions. I'm not opposed of going modular, it just see= ms=20 that going modular for the sake of one directory is a bit of an overkill. > >Is there a real benefit in creating another rc.d script for doing this a= nd > >adding a knob to turn creation of these directories off? > > Even more critical paths in the boot process are controlled in this > manner. Why not? As I said, I'm not opposed of doing it in this manner, I just don't see the= =20 real need to create several additional scripts instead of changing two line= s=20 in existing one that already takes care of cleaning (and preparing) /tmp=20 directory. > >Yes of course that would only solve things on -current and -stable, > > however > > This was allways the main problem of solve this 'only base'. > > >there is already an UPDATING entry for this and we can always add a scri= pt > > to be installed from a port that would take care of transition period > > (probably as soon in dependency tree as possible, ie -libraries). > > There are PRs on this. I think that latest rcNG script (with perhaps > some tweaks to work from ports) installed from Xorg libraries will be > the better first step. We may make this install_script conditional when > we have the problem solved in RELENG_5 base (test OS_VERSION) and lost > this when RELENG_4 life cycle was expired. I'm aware of the PRs on this, I wanted to voice my opinion on the particula= r=20 problem of creating a directory /tmp/.ICE-unix with right permissions. Allow me to ramble a bit more on these: If we go to "modular" way as you pu= t=20 it, the we would have to add a script to create ICE-unix directory to, say,= =20 =2Dlibraries ports and a script to remove lock file and X11-unix to -server= =20 ports (more than two of them), while being careful not to let different=20 =2Dserver ports (as in server and nestserver...) step onto each others toes= =2E Or=20 we could make additional port to only install one rc script. This is=20 certainly doable and would of course be more or less modular and could even= =20 have knobs so one could choose if directories should be created/removed and= =20 if lock file should be created/removed. I can't help but to think that this= =20 would be using a bit tooo enormous hammer, that's why I still think a simpl= e=20 solution proposed by Pawel Worach would be enough here. Dejan From owner-freebsd-x11@FreeBSD.ORG Wed Jan 12 23:40:31 2005 Return-Path: Delivered-To: freebsd-x11@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB9A716A4D7 for ; Wed, 12 Jan 2005 23:40:31 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8932843D2D for ; Wed, 12 Jan 2005 23:40:31 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j0CNeVWw029834 for ; Wed, 12 Jan 2005 23:40:31 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j0CNeVgU029833; Wed, 12 Jan 2005 23:40:31 GMT (envelope-from gnats) Date: Wed, 12 Jan 2005 23:40:31 GMT Message-Id: <200501122340.j0CNeVgU029833@freefall.freebsd.org> To: freebsd-x11@FreeBSD.org From: Eric Anholt Subject: Re: ports/76115 X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Eric Anholt List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 23:40:32 -0000 The following reply was made to PR ports/76115; it has been noted by GNATS. From: Eric Anholt To: gnats Cc: Subject: Re: ports/76115 Date: Wed, 12 Jan 2005 15:39:58 -0800 I and another developer have failed to reproduce this on the sample image you provided in firefox or the gimp. This suggests that those programs are simply failing when they meet an unexpected resource shortage that we aren't experiencing, which would be just what a BadAlloc would be returned for on a very large image. Given that these errors are rare under normal circumstances, it's understandable that applications tend to fail when they occur, but that doesn't change that it is the application's fault for not handling them. Thus, these errors should be taken up with the upstream of those applications, unless it can be shown that this clearly doesn't occur with different versions of X and is a new regression (but again, WORKSFORME). -- Eric Anholt eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org From owner-freebsd-x11@FreeBSD.ORG Wed Jan 12 23:46:52 2005 Return-Path: Delivered-To: freebsd-x11@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42C1416A4CE; Wed, 12 Jan 2005 23:46:52 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1870443D39; Wed, 12 Jan 2005 23:46:52 +0000 (GMT) (envelope-from anholt@FreeBSD.org) Received: from freefall.freebsd.org (anholt@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j0CNkpbA030318; Wed, 12 Jan 2005 23:46:51 GMT (envelope-from anholt@freefall.freebsd.org) Received: (from anholt@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j0CNkpoX030314; Wed, 12 Jan 2005 23:46:51 GMT (envelope-from anholt) Date: Wed, 12 Jan 2005 23:46:51 GMT From: Eric Anholt Message-Id: <200501122346.j0CNkpoX030314@freefall.freebsd.org> To: josh@hewbert.com, anholt@FreeBSD.org, freebsd-x11@FreeBSD.org Subject: Re: ports/76115: xorg-libraries-6.8.1: apps crashing on large images (BadAlloc) X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 23:46:52 -0000 Synopsis: xorg-libraries-6.8.1: apps crashing on large images (BadAlloc) State-Changed-From-To: open->closed State-Changed-By: anholt State-Changed-When: Wed Jan 12 23:46:20 GMT 2005 State-Changed-Why: Closed, as this is a PR for two application bugs (afaict) which should be pursued in upstream bugtrackers. http://www.freebsd.org/cgi/query-pr.cgi?pr=76115 From owner-freebsd-x11@FreeBSD.ORG Thu Jan 13 02:27:21 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 002B516A4CE; Thu, 13 Jan 2005 02:27:20 +0000 (GMT) Received: from 212.106.238.57.adsl.jazztel.es (212.106.238.57.adsl.jazztel.es [212.106.238.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C39E43D2F; Thu, 13 Jan 2005 02:27:19 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from [192.168.254.16] (orion.redesjm.local [192.168.254.16]) j0D2RCml008203; Thu, 13 Jan 2005 03:27:13 +0100 (CET) (envelope-from freebsd@redesjm.local) Message-ID: <41E5DC84.60608@redesjm.local> Date: Thu, 13 Jan 2005 03:27:16 +0100 From: Jose M Rodriguez User-Agent: Mozilla Thunderbird 1.0 (X11/20050106) X-Accept-Language: es-es, es MIME-Version: 1.0 To: Dejan Lesjak References: <1105321614.8452.54.camel@leguin> <200501102003.35785.dejan.lesjak@ijs.si> <41E2DD07.6010607@redesjm.local> <200501121809.46129.dejan.lesjak@ijs.si> In-Reply-To: <200501121809.46129.dejan.lesjak@ijs.si> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.29.0.5; VDF: 6.29.0.31; host: antares.redesjm.local) cc: freebsd-rc@freebsd.org cc: freebsd-x11@freebsd.org cc: x11@freebsd.org Subject: Re: x11 /tmp preparation rc.d script X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 02:27:21 -0000 Dejan Lesjak escribió: >On Monday 10 of January 2005 20:52, Jose M Rodriguez wrote: > > >>Dejan Lesjak escribió: >> >> >>>Other than that, I don't really know what would be the best way to handle >>>creation of this directories and haven't commented so far, but since I'm >>>already writing (mostly because I thought rc@ list should be CCed), here's >>>my opinion FWIW: the simplest seems to be a patch from Pawel Worach at >>>http://lists.freebsd.org/mailman/htdig/freebsd-current/2004-November/0424 >>>45.html The benefit of using this simple approach is that it is simple (of >>>course :) and furthermore it only adds two more directories to /tmp at >>>startup as oposed to adding a file in /etc/rc.d. The difference being one >>>inode. But then again, perhaps I don't see all the implications and this >>>is too simple. >>> >>> >>The only I know is that this breaks rcNG writing rules. This is a >>little more than style. I think that goin more modular can't hurt. >> >> > >Well it is certainly an exception to how rcNG scripts are otherwise written, >but I don't see this as a bad thing. Creation of /tmp/.X11-unix and removal >of X lock file is already there as that seems the right place to do that. >Because of this it also seems natural (to me at least) to just add creation >of another dir there. I believe that having this in this script makes things >done at the right time - if one has configured to have /tmp directory cleaned >after boot, then things that should be recreated are recreated right after >that; if no other explicitly ordered cleaning up is done, these directories >(and a lock file) are still "cleaned" away and recreated with side effect of >having the right permissions. I'm not opposed of going modular, it just seems >that going modular for the sake of one directory is a bit of an overkill. > > > >>>Is there a real benefit in creating another rc.d script for doing this and >>>adding a knob to turn creation of these directories off? >>> >>> >>Even more critical paths in the boot process are controlled in this >>manner. Why not? >> >> > >As I said, I'm not opposed of doing it in this manner, I just don't see the >real need to create several additional scripts instead of changing two lines >in existing one that already takes care of cleaning (and preparing) /tmp >directory. > > > >>>Yes of course that would only solve things on -current and -stable, >>>however >>> >>> >>This was allways the main problem of solve this 'only base'. >> >> >> >>>there is already an UPDATING entry for this and we can always add a script >>>to be installed from a port that would take care of transition period >>>(probably as soon in dependency tree as possible, ie -libraries). >>> >>> >>There are PRs on this. I think that latest rcNG script (with perhaps >>some tweaks to work from ports) installed from Xorg libraries will be >>the better first step. We may make this install_script conditional when >>we have the problem solved in RELENG_5 base (test OS_VERSION) and lost >>this when RELENG_4 life cycle was expired. >> >> > >I'm aware of the PRs on this, I wanted to voice my opinion on the particular >problem of creating a directory /tmp/.ICE-unix with right permissions. >Allow me to ramble a bit more on these: If we go to "modular" way as you put >it, the we would have to add a script to create ICE-unix directory to, say, >-libraries ports and a script to remove lock file and X11-unix to -server >ports (more than two of them), while being careful not to let different >-server ports (as in server and nestserver...) step onto each others toes. Or >we could make additional port to only install one rc script. This is >certainly doable and would of course be more or less modular and could even >have knobs so one could choose if directories should be created/removed and >if lock file should be created/removed. I can't help but to think that this >would be using a bit tooo enormous hammer, that's why I still think a simple >solution proposed by Pawel Worach would be enough here. > >Dejan > > > > This is really a classic issue. Of course, you may choose, but what you like as a X11 hacker may not be so good for a rc hacker. In this aspect, going modular is more a system eng. need. It's not so direct think that a 'cleartmp' component is so vital for 'x11'. Also, as this is done in cleartmp, you don't have a checkyesno control over the code, as you have in common rcNG scripts. This is exec 'fully inconditional'. What I don't like is add even more params to this without control, but I don't have objetions to maintain the hack with the new needed support. -- josemi From owner-freebsd-x11@FreeBSD.ORG Thu Jan 13 02:27:21 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 002B516A4CE; Thu, 13 Jan 2005 02:27:20 +0000 (GMT) Received: from 212.106.238.57.adsl.jazztel.es (212.106.238.57.adsl.jazztel.es [212.106.238.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C39E43D2F; Thu, 13 Jan 2005 02:27:19 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from [192.168.254.16] (orion.redesjm.local [192.168.254.16]) j0D2RCml008203; Thu, 13 Jan 2005 03:27:13 +0100 (CET) (envelope-from freebsd@redesjm.local) Message-ID: <41E5DC84.60608@redesjm.local> Date: Thu, 13 Jan 2005 03:27:16 +0100 From: Jose M Rodriguez User-Agent: Mozilla Thunderbird 1.0 (X11/20050106) X-Accept-Language: es-es, es MIME-Version: 1.0 To: Dejan Lesjak References: <1105321614.8452.54.camel@leguin> <200501102003.35785.dejan.lesjak@ijs.si> <41E2DD07.6010607@redesjm.local> <200501121809.46129.dejan.lesjak@ijs.si> In-Reply-To: <200501121809.46129.dejan.lesjak@ijs.si> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.29.0.5; VDF: 6.29.0.31; host: antares.redesjm.local) cc: freebsd-rc@freebsd.org cc: freebsd-x11@freebsd.org cc: x11@freebsd.org Subject: Re: x11 /tmp preparation rc.d script X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 02:27:21 -0000 Dejan Lesjak escribió: >On Monday 10 of January 2005 20:52, Jose M Rodriguez wrote: > > >>Dejan Lesjak escribió: >> >> >>>Other than that, I don't really know what would be the best way to handle >>>creation of this directories and haven't commented so far, but since I'm >>>already writing (mostly because I thought rc@ list should be CCed), here's >>>my opinion FWIW: the simplest seems to be a patch from Pawel Worach at >>>http://lists.freebsd.org/mailman/htdig/freebsd-current/2004-November/0424 >>>45.html The benefit of using this simple approach is that it is simple (of >>>course :) and furthermore it only adds two more directories to /tmp at >>>startup as oposed to adding a file in /etc/rc.d. The difference being one >>>inode. But then again, perhaps I don't see all the implications and this >>>is too simple. >>> >>> >>The only I know is that this breaks rcNG writing rules. This is a >>little more than style. I think that goin more modular can't hurt. >> >> > >Well it is certainly an exception to how rcNG scripts are otherwise written, >but I don't see this as a bad thing. Creation of /tmp/.X11-unix and removal >of X lock file is already there as that seems the right place to do that. >Because of this it also seems natural (to me at least) to just add creation >of another dir there. I believe that having this in this script makes things >done at the right time - if one has configured to have /tmp directory cleaned >after boot, then things that should be recreated are recreated right after >that; if no other explicitly ordered cleaning up is done, these directories >(and a lock file) are still "cleaned" away and recreated with side effect of >having the right permissions. I'm not opposed of going modular, it just seems >that going modular for the sake of one directory is a bit of an overkill. > > > >>>Is there a real benefit in creating another rc.d script for doing this and >>>adding a knob to turn creation of these directories off? >>> >>> >>Even more critical paths in the boot process are controlled in this >>manner. Why not? >> >> > >As I said, I'm not opposed of doing it in this manner, I just don't see the >real need to create several additional scripts instead of changing two lines >in existing one that already takes care of cleaning (and preparing) /tmp >directory. > > > >>>Yes of course that would only solve things on -current and -stable, >>>however >>> >>> >>This was allways the main problem of solve this 'only base'. >> >> >> >>>there is already an UPDATING entry for this and we can always add a script >>>to be installed from a port that would take care of transition period >>>(probably as soon in dependency tree as possible, ie -libraries). >>> >>> >>There are PRs on this. I think that latest rcNG script (with perhaps >>some tweaks to work from ports) installed from Xorg libraries will be >>the better first step. We may make this install_script conditional when >>we have the problem solved in RELENG_5 base (test OS_VERSION) and lost >>this when RELENG_4 life cycle was expired. >> >> > >I'm aware of the PRs on this, I wanted to voice my opinion on the particular >problem of creating a directory /tmp/.ICE-unix with right permissions. >Allow me to ramble a bit more on these: If we go to "modular" way as you put >it, the we would have to add a script to create ICE-unix directory to, say, >-libraries ports and a script to remove lock file and X11-unix to -server >ports (more than two of them), while being careful not to let different >-server ports (as in server and nestserver...) step onto each others toes. Or >we could make additional port to only install one rc script. This is >certainly doable and would of course be more or less modular and could even >have knobs so one could choose if directories should be created/removed and >if lock file should be created/removed. I can't help but to think that this >would be using a bit tooo enormous hammer, that's why I still think a simple >solution proposed by Pawel Worach would be enough here. > >Dejan > > > > This is really a classic issue. Of course, you may choose, but what you like as a X11 hacker may not be so good for a rc hacker. In this aspect, going modular is more a system eng. need. It's not so direct think that a 'cleartmp' component is so vital for 'x11'. Also, as this is done in cleartmp, you don't have a checkyesno control over the code, as you have in common rcNG scripts. This is exec 'fully inconditional'. What I don't like is add even more params to this without control, but I don't have objetions to maintain the hack with the new needed support. -- josemi From owner-freebsd-x11@FreeBSD.ORG Thu Jan 13 04:46:07 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6674C16A4CE for ; Thu, 13 Jan 2005 04:46:07 +0000 (GMT) Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25F8443D1F for ; Thu, 13 Jan 2005 04:46:07 +0000 (GMT) (envelope-from M.Santhoff@t-online.de) Received: from fwd05.aul.t-online.de by mailout06.sul.t-online.com with smtp id 1Cowrz-0005nb-00; Thu, 13 Jan 2005 05:46:03 +0100 Received: from localhost.das.netz (Ew+qjuZvwed1UIY5mKBCawIfwk0x5z-NXm0RA1w51+wCaV5ZtXDLgr@[217.251.166.199]) by fwd05.sul.t-online.com with esmtp id 1Cowrm-10fV3o0; Thu, 13 Jan 2005 05:45:50 +0100 Received: from [10.0.0.3] (zaphod.das.netz [10.0.0.3]) by localhost.das.netz (8.12.10/8.12.10) with ESMTP id j0D4glsD071799 for ; Thu, 13 Jan 2005 05:42:47 +0100 (CET) (envelope-from M.Santhoff@t-online.de) From: M.Santhoff@t-online.de (Marc Santhoff) To: freebsd-x11@freebsd.org Content-Type: text/plain Message-Id: <1105591556.314.18.camel@zaphod.das.netz> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 13 Jan 2005 05:45:56 +0100 Content-Transfer-Encoding: 7bit X-ID: Ew+qjuZvwed1UIY5mKBCawIfwk0x5z-NXm0RA1w51+wCaV5ZtXDLgr X-TOI-MSGID: 9b85438a-4524-4e3b-8b58-eadf59bdde79 Subject: enabling driver in XFree X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 04:46:07 -0000 Hi, I've tried to enable an additional XInput-driver by uncommenting it in "xf86site.def" but this file is overwritten by the FreeBSD build process. How is this expected to be done? TIA, Marc From owner-freebsd-x11@FreeBSD.ORG Thu Jan 13 11:20:12 2005 Return-Path: Delivered-To: freebsd-x11@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B970B16A4CF for ; Thu, 13 Jan 2005 11:20:12 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86BA043D39 for ; Thu, 13 Jan 2005 11:20:12 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j0DBKCSE053468 for ; Thu, 13 Jan 2005 11:20:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j0DBKCAC053467; Thu, 13 Jan 2005 11:20:12 GMT (envelope-from gnats) Date: Thu, 13 Jan 2005 11:20:12 GMT Message-Id: <200501131120.j0DBKCAC053467@freefall.freebsd.org> To: freebsd-x11@FreeBSD.org From: Tod McQuillin Subject: Re: ports/75666: add Matrox MGA Driver to xorg-server X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Tod McQuillin List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 11:20:12 -0000 The following reply was made to PR ports/75666; it has been noted by GNATS. From: Tod McQuillin To: freebsd-gnats-submit@FreeBSD.org, oliver@freebsd.org Cc: Subject: Re: ports/75666: add Matrox MGA Driver to xorg-server Date: Thu, 13 Jan 2005 20:12:22 +0900 (JST) I can confirm that this works brilliantly on RELENG_4 as well, although the patch might not be in exactly the right format. Thank goodness this works, too, as it's absolutely needed to get xorg working with the matrox G550 when using DVI displays. Here's a version of the patch relative to cwd instead of to /usr/ports/x11-servers: Index: Makefile =================================================================== RCS file: /usr/src/cvs-repo/ports/x11-servers/xorg-server/Makefile,v retrieving revision 1.20 diff -u -u -r1.20 Makefile --- Makefile 2 Jan 2005 00:32:06 -0000 1.20 +++ Makefile 13 Jan 2005 10:05:06 -0000 @@ -137,6 +137,38 @@ PLIST_SUB+= AMD64_I386="@comment " .endif +.if ${ARCH} == i386 +.if !defined(WITH_MATROX_GXX_DRIVER) +SCRIPTS_ENV+= HaveMatroxHal=NO +PLIST_SUB+= MATROX="@comment " +pre-fetch:: + @${ECHO_MSG} "********************************************************" + @${ECHO_MSG} "Define WITH_MATROX_GXX_DRIVER to include Matrox's extra" + @${ECHO_MSG} "\"HALLIB\" binary driver" + @${ECHO_MSG} "********************************************************" +.else +NO_PACKAGE= "Matrox drivers may not be distributed" +RESTRICTED= "Matrox drivers may not be distributed." +EXTRA_PATCHES= ${FILESDIR}/extra-patch-matrox +SCRIPTS_ENV+= HaveMatroxHal=YES +MGA_DRIVER_VERSION= 4.1-1 +MASTER_SITES+= ftp://ftp.matrox.com/pub/mga/archive/linux/2004/:mga +DISTFILES+= mgadriver-${MGA_DRIVER_VERSION}-src.tar.gz:mga +#EXTRACT_ONLY+= mgadriver-${MGA_DRIVER_VERSION}-src.tar.gz +RESTRICTED_FILES= mgadriver-${MGA_DRIVER_VERSION}-src.tar.gz +PLIST_SUB+= MATROX="" +post-extract:: + ${CP} -r ${WRKDIR}/mgadriver-${MGA_DRIVER_VERSION}-src/${PORTVERSION}/mga \ + ${WRKSRC}/programs/Xserver/hw/xfree86/drivers/ +post-install:: + ${INSTALL_DATA} ${WRKDIR}/mgadriver-${MGA_DRIVER_VERSION}-src/${PORTVERSION}/mga/README_HALLIB \ + ${PREFIX}/lib/X11/doc/README.mga_HALLIB +.endif # !WITH_MATROX_GXX_DRIVER +.else +SCRIPTS_ENV+= HaveMatroxHal=NO +PLIST_SUB+= MATROX="@comment " +.endif + .if !defined(NO_SUID_XSERVER) || ${NO_SUID_XSERVER} == NO pre-everything:: @${ECHO_MSG} "By default, the X Server installs as a set-user-id root binary. When run by" Index: distinfo =================================================================== RCS file: /usr/src/cvs-repo/ports/x11-servers/xorg-server/distinfo,v retrieving revision 1.2 diff -u -u -r1.2 distinfo --- distinfo 23 Dec 2004 01:35:48 -0000 1.2 +++ distinfo 13 Jan 2005 10:02:34 -0000 @@ -2,3 +2,5 @@ SIZE (xorg/X11R6.8.1-src1.tar.gz) = 30562401 MD5 (xorg/X11R6.8.1-src3.tar.gz) = 8578e566e909e7c40300f44b6f0e88d3 SIZE (xorg/X11R6.8.1-src3.tar.gz) = 10014808 +MD5 (xorg/mgadriver-4.1-1-src.tar.gz) = 5376fed39733b605191cf4dbb138a3ff +SIZE(xorg/mgadriver-4.1-1-src.tar.gz) = 1148470 Index: pkg-plist =================================================================== RCS file: /usr/src/cvs-repo/ports/x11-servers/xorg-server/pkg-plist,v retrieving revision 1.6 diff -u -u -r1.6 pkg-plist --- pkg-plist 2 Jan 2005 00:32:06 -0000 1.6 +++ pkg-plist 13 Jan 2005 10:02:34 -0000 @@ -63,6 +63,7 @@ lib/X11/doc/README.fonts lib/X11/doc/README.i740 lib/X11/doc/README.i810 +%%MATROX%%lib/X11/doc/README.mga_HALLIB lib/X11/doc/README.mouse lib/X11/doc/README.newport lib/X11/doc/README.r128 @@ -93,6 +94,7 @@ %%I386%%lib/modules/drivers/i740_drv.o %%I386%%lib/modules/drivers/i810_drv.o lib/modules/drivers/mga_drv.o +%%MATROX%%lib/modules/drivers/mga_hal_drv.o %%AMD64_I386%%lib/modules/drivers/neomagic_drv.o %%I386%%lib/modules/drivers/nsc_drv.o %%SPARC64_NA%%lib/modules/drivers/nv_drv.o Index: files/extra-patch-matrox =================================================================== RCS file: files/extra-patch-matrox diff -N files/extra-patch-matrox --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ files/extra-patch-matrox 13 Jan 2005 10:02:34 -0000 @@ -0,0 +1,17 @@ +--- programs/Xserver/hw/xfree86/drivers/mga/Imakefile.orig Sun Jan 9 01:14:42 2005 ++++ programs/Xserver/hw/xfree86/drivers/mga/Imakefile Sun Jan 9 01:14:48 2005 +@@ -6,6 +6,14 @@ + #define IHaveModules + #include + ++#undef NormalRelocatableTarget ++#define NormalRelocatableTarget(objname,objlist) @@\ ++AllTarget(objname.Osuf) @@\ ++ @@\ ++objname.Osuf: objlist $(EXTRALIBRARYDEPS) @@\ ++ RemoveFile($@) @@\ ++ $(MODLD) $(MODLDCOMBINEFLAGS) objlist -L../../i2c -li2c -o $@ ++ + #if BuildMatroxHal + #define IHaveSubdirs + SUBDIRS=hallib Index: scripts/configure =================================================================== RCS file: /usr/src/cvs-repo/ports/x11-servers/xorg-server/scripts/configure,v retrieving revision 1.5 diff -u -u -r1.5 configure --- scripts/configure 2 Jan 2005 00:32:07 -0000 1.5 +++ scripts/configure 13 Jan 2005 10:02:34 -0000 @@ -24,6 +24,8 @@ echo "#define UseInstalledPrograms YES" >> $LOCALDEF echo "#define StandardIncludes -I${PREFIX}/include" >> $LOCALDEF echo "#define BuildXFree86ConfigTools YES" >> $LOCALDEF +# Matrox driver support +echo "#define HaveMatroxHal $HaveMatroxHal" >> $LOCALDEF if [ X$WITH_DEBUG != X ]; then export CFLAGS="-g $CFLAGS" From owner-freebsd-x11@FreeBSD.ORG Thu Jan 13 13:40:51 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD02316A4CE for ; Thu, 13 Jan 2005 13:40:51 +0000 (GMT) Received: from niobe.ijs.si (mail.ijs.si [193.2.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA3D643D45 for ; Thu, 13 Jan 2005 13:40:50 +0000 (GMT) (envelope-from dejan.lesjak@ijs.si) Received: from localhost (localhost.ijs.si [127.0.0.1]) by niobe.ijs.si (Postfix) with ESMTP id 057D81DD614; Thu, 13 Jan 2005 14:40:50 +0100 (CET) Received: from niobe.ijs.si ([127.0.0.1]) by localhost (niobe.ijs.si [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58621-03; Thu, 13 Jan 2005 14:40:37 +0100 (CET) Received: from metatron.ijs.si (metatron.ijs.si [193.2.4.152]) by niobe.ijs.si (Postfix) with ESMTP id 9A6811DD5CD; Thu, 13 Jan 2005 14:40:34 +0100 (CET) Received: from idefix.ijs.si (idefix.ijs.si [193.2.4.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by metatron.ijs.si (Postfix) with ESMTP id 7C1C81C0072B; Thu, 13 Jan 2005 14:40:34 +0100 (CET) From: Dejan Lesjak To: freebsd-x11@freebsd.org Date: Thu, 13 Jan 2005 14:40:33 +0100 User-Agent: KMail/1.7.2 References: <1105591556.314.18.camel@zaphod.das.netz> In-Reply-To: <1105591556.314.18.camel@zaphod.das.netz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200501131440.33884.dejan.lesjak@ijs.si> X-Virus-Scanned: amavisd-new at ijs.si cc: Marc Santhoff Subject: Re: enabling driver in XFree X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 13:40:52 -0000 On Thursday 13 of January 2005 05:45, Marc Santhoff wrote: > Hi, > > I've tried to enable an additional XInput-driver by uncommenting it in > "xf86site.def" but this file is overwritten by the FreeBSD build > process. > > How is this expected to be done? > > TIA, > Marc I don't think it's really expected :) You would need to modify scripts/configure file in XFree86-4-Server port directory. Which driver is it? Would it make sense to install it by default? Dejan From owner-freebsd-x11@FreeBSD.ORG Thu Jan 13 14:08:08 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C0B516A4CE for ; Thu, 13 Jan 2005 14:08:08 +0000 (GMT) Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78ABD43D31 for ; Thu, 13 Jan 2005 14:08:07 +0000 (GMT) (envelope-from M.Santhoff@t-online.de) Received: from fwd03.aul.t-online.de by mailout06.sul.t-online.com with smtp id 1Cp5dt-0004d3-01; Thu, 13 Jan 2005 15:08:05 +0100 Received: from localhost.das.netz (rSmGw+ZareNPcu1Z07fBrsAkSkD2lwqz9G4cgAD1xEh2npLOKuPj4b@[217.251.166.147]) by fwd03.sul.t-online.com with esmtp id 1Cp5dg-1uLLzk0; Thu, 13 Jan 2005 15:07:52 +0100 Received: from [10.0.0.3] (zaphod.das.netz [10.0.0.3]) by localhost.das.netz (8.12.10/8.12.10) with ESMTP id j0DE1tsD072679 for ; Thu, 13 Jan 2005 15:01:56 +0100 (CET) (envelope-from M.Santhoff@t-online.de) From: M.Santhoff@t-online.de (Marc Santhoff) To: freebsd-x11@freebsd.org In-Reply-To: <200501131440.33884.dejan.lesjak@ijs.si> References: <1105591556.314.18.camel@zaphod.das.netz> <200501131440.33884.dejan.lesjak@ijs.si> Content-Type: text/plain Message-Id: <1105625102.265.14.camel@zaphod.das.netz> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 13 Jan 2005 15:05:02 +0100 Content-Transfer-Encoding: 7bit X-ID: rSmGw+ZareNPcu1Z07fBrsAkSkD2lwqz9G4cgAD1xEh2npLOKuPj4b X-TOI-MSGID: 30c04694-6f0f-49a8-bd49-0116dcda669c Subject: Re: enabling driver in XFree X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 14:08:08 -0000 Am Do, den 13.01.2005 schrieb Dejan Lesjak um 14:40: > On Thursday 13 of January 2005 05:45, Marc Santhoff wrote: > > Hi, > > > > I've tried to enable an additional XInput-driver by uncommenting it in > > "xf86site.def" but this file is overwritten by the FreeBSD build > > process. > > > > How is this expected to be done? > > > > TIA, > > Marc > > I don't think it's really expected :) You would need to modify > scripts/configure file in XFree86-4-Server port directory. > Which driver is it? Would it make sense to install it by default? It's the "aiptek" driver and no, it does not make any sense to activate it since there's no support for the device itself. With pure "/dev/uhid" it doesn't work properly, as I found out in the meantime. Bye, Marc From owner-freebsd-x11@FreeBSD.ORG Thu Jan 13 14:24:55 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0062716A4CE; Thu, 13 Jan 2005 14:24:55 +0000 (GMT) Received: from mail.cs.ait.ac.th (mail.cs.ait.ac.th [192.41.170.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76F5543D1D; Thu, 13 Jan 2005 14:24:53 +0000 (GMT) (envelope-from on@cs.ait.ac.th) Received: from banyan.cs.ait.ac.th (banyan.cs.ait.ac.th [192.41.170.5]) by mail.cs.ait.ac.th (8.12.11/8.12.11) with ESMTP id j0DEOo7S060829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Jan 2005 21:24:50 +0700 (ICT) Received: (from on@localhost) by banyan.cs.ait.ac.th (8.13.1/8.12.11) id j0DEOnvw001009; Thu, 13 Jan 2005 21:24:49 +0700 (ICT) Date: Thu, 13 Jan 2005 21:24:49 +0700 (ICT) Message-Id: <200501131424.j0DEOnvw001009@banyan.cs.ait.ac.th> From: Olivier Nicole To: freebsd-x11@freebsd.org, freebsd-questions@freebsd.org X-Virus-Scanned: on CSIM by amavisd-milter (http://www.amavis.org/) Subject: Cut and paste in Emacs X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 14:24:55 -0000 Hi, There is that strange and annoying behaviours that I have noticed with Emacs 21.3.1. Other versions I used to use were in the 19ish and had no problem. When I select some text with the mouse in Emacs, i can copy it into another X window application, but I cannot copy it in a Win2K application. When I select some text in any other X Window application, I can copy it into Win2k, so the mechanism select in X, paste in w2k is working. So now when I want to copy/paste from emacs to w2k, I have to paste in some other place, select again and finally paste in w2k. Any clue/help would be welcome. best regards, Olivier From owner-freebsd-x11@FreeBSD.ORG Thu Jan 13 15:00:30 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C4F216A4CE for ; Thu, 13 Jan 2005 15:00:30 +0000 (GMT) Received: from niobe.ijs.si (mail.ijs.si [193.2.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA0C543D45 for ; Thu, 13 Jan 2005 15:00:28 +0000 (GMT) (envelope-from dejan.lesjak@ijs.si) Received: from localhost (localhost.ijs.si [127.0.0.1]) by niobe.ijs.si (Postfix) with ESMTP id 2592F1DD64A; Thu, 13 Jan 2005 16:00:28 +0100 (CET) Received: from niobe.ijs.si ([127.0.0.1]) by localhost (niobe.ijs.si [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72505-09-3; Thu, 13 Jan 2005 16:00:17 +0100 (CET) Received: from metatron.ijs.si (metatron.ijs.si [193.2.4.152]) by niobe.ijs.si (Postfix) with ESMTP id 159C41DD60A; Thu, 13 Jan 2005 16:00:17 +0100 (CET) Received: from idefix.ijs.si (idefix.ijs.si [193.2.4.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by metatron.ijs.si (Postfix) with ESMTP id 0E21A1C00728; Thu, 13 Jan 2005 16:00:16 +0100 (CET) From: Dejan Lesjak To: freebsd-x11@freebsd.org Date: Thu, 13 Jan 2005 16:00:15 +0100 User-Agent: KMail/1.7.2 References: <1105591556.314.18.camel@zaphod.das.netz> <200501131440.33884.dejan.lesjak@ijs.si> <1105625102.265.14.camel@zaphod.das.netz> In-Reply-To: <1105625102.265.14.camel@zaphod.das.netz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200501131600.16371.dejan.lesjak@ijs.si> X-Virus-Scanned: amavisd-new at ijs.si cc: Marc Santhoff Subject: Re: enabling driver in XFree X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 15:00:30 -0000 On Thursday 13 of January 2005 15:05, Marc Santhoff wrote: > Am Do, den 13.01.2005 schrieb Dejan Lesjak um 14:40: > > On Thursday 13 of January 2005 05:45, Marc Santhoff wrote: > > > Hi, > > > > > > I've tried to enable an additional XInput-driver by uncommenting it in > > > "xf86site.def" but this file is overwritten by the FreeBSD build > > > process. > > > > > > How is this expected to be done? > > > > > > TIA, > > > Marc > > > > I don't think it's really expected :) You would need to modify > > scripts/configure file in XFree86-4-Server port directory. > > Which driver is it? Would it make sense to install it by default? > > It's the "aiptek" driver and no, it does not make any sense to activate > it since there's no support for the device itself. With pure "/dev/uhid" > it doesn't work properly, as I found out in the meantime. > > Bye, > Marc Unfortunately. That would also be the reason why it's build is disabled - in general all the drivers that would work should also be built, so if/when there is a kernel driver available for this device, would you please ping us here so it gets included by default. Dejan From owner-freebsd-x11@FreeBSD.ORG Thu Jan 13 20:54:18 2005 Return-Path: Delivered-To: freebsd-x11@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C817516A4D1; Thu, 13 Jan 2005 20:54:18 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0BF743D1D; Thu, 13 Jan 2005 20:54:18 +0000 (GMT) (envelope-from anholt@FreeBSD.org) Received: from freefall.freebsd.org (anholt@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j0DKsIhf023080; Thu, 13 Jan 2005 20:54:18 GMT (envelope-from anholt@freefall.freebsd.org) Received: (from anholt@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j0DKsIqQ023076; Thu, 13 Jan 2005 20:54:18 GMT (envelope-from anholt) Date: Thu, 13 Jan 2005 20:54:18 GMT From: Eric Anholt Message-Id: <200501132054.j0DKsIqQ023076@freefall.freebsd.org> To: oliver@freebsd.org, anholt@FreeBSD.org, freebsd-x11@FreeBSD.org Subject: Re: ports/75666: add Matrox MGA Driver to xorg-server X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 20:54:18 -0000 Synopsis: add Matrox MGA Driver to xorg-server State-Changed-From-To: open->closed State-Changed-By: anholt State-Changed-When: Thu Jan 13 20:52:48 GMT 2005 State-Changed-Why: I've committed an mga_hal port in x11-servers which I believe does all that's necessary for MGA HAL support, without cluttering up xorg-server. (I read the diffs and didn't see things that seemed too major, but please tell me if there are pieces of Matrox's code that are necessary). http://www.freebsd.org/cgi/query-pr.cgi?pr=75666 From owner-freebsd-x11@FreeBSD.ORG Thu Jan 13 20:55:26 2005 Return-Path: Delivered-To: freebsd-x11@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2574816A4CF; Thu, 13 Jan 2005 20:55:26 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id F14FD43D49; Thu, 13 Jan 2005 20:55:25 +0000 (GMT) (envelope-from anholt@FreeBSD.org) Received: from freefall.freebsd.org (anholt@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j0DKtPOl023428; Thu, 13 Jan 2005 20:55:25 GMT (envelope-from anholt@freefall.freebsd.org) Received: (from anholt@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j0DKtPmb023424; Thu, 13 Jan 2005 20:55:25 GMT (envelope-from anholt) Date: Thu, 13 Jan 2005 20:55:25 GMT From: Eric Anholt Message-Id: <200501132055.j0DKtPmb023424@freefall.freebsd.org> To: rehsack@liwing.de, anholt@FreeBSD.org, freebsd-x11@FreeBSD.org Subject: Re: ports/55699: [PATCH] making x11-servers/XFree86-4-Server able to use mga hal library X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 20:55:26 -0000 Synopsis: [PATCH] making x11-servers/XFree86-4-Server able to use mga hal library State-Changed-From-To: suspended->closed State-Changed-By: anholt State-Changed-When: Thu Jan 13 20:54:30 GMT 2005 State-Changed-Why: Port of mga_hal 4.1 committed. The current changes to the open-source pieces seemed unimportant, but I could be wrong. Please tell me if there are issues with the mga_hal currently, compared to dropping Matrox's sources in. http://www.freebsd.org/cgi/query-pr.cgi?pr=55699 From owner-freebsd-x11@FreeBSD.ORG Thu Jan 13 23:00:34 2005 Return-Path: Delivered-To: freebsd-x11@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3FC2616A4CF; Thu, 13 Jan 2005 23:00:34 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1627743D46; Thu, 13 Jan 2005 23:00:34 +0000 (GMT) (envelope-from anholt@FreeBSD.org) Received: from freefall.freebsd.org (anholt@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j0DN0XNE039612; Thu, 13 Jan 2005 23:00:33 GMT (envelope-from anholt@freefall.freebsd.org) Received: (from anholt@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j0DN0Xs0039608; Thu, 13 Jan 2005 23:00:33 GMT (envelope-from anholt) Date: Thu, 13 Jan 2005 23:00:33 GMT From: Eric Anholt Message-Id: <200501132300.j0DN0Xs0039608@freefall.freebsd.org> To: dot@dotat.at, anholt@FreeBSD.org, freebsd-x11@FreeBSD.org Subject: Re: ports/25576: XFree86-4 port installs manual pages with clashing names X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 23:00:34 -0000 Synopsis: XFree86-4 port installs manual pages with clashing names State-Changed-From-To: feedback->patched State-Changed-By: anholt State-Changed-When: Thu Jan 13 23:00:10 GMT 2005 State-Changed-Why: Fixed for xorg-server, leaving open for lesi@ to pick up for XFree86-4-Server. http://www.freebsd.org/cgi/query-pr.cgi?pr=25576 From owner-freebsd-x11@FreeBSD.ORG Thu Jan 13 23:03:08 2005 Return-Path: Delivered-To: freebsd-x11@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5994616A4CE; Thu, 13 Jan 2005 23:03:08 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FD9143D49; Thu, 13 Jan 2005 23:03:08 +0000 (GMT) (envelope-from anholt@FreeBSD.org) Received: from freefall.freebsd.org (anholt@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j0DN38lj039856; Thu, 13 Jan 2005 23:03:08 GMT (envelope-from anholt@freefall.freebsd.org) Received: (from anholt@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j0DN37Tp039852; Thu, 13 Jan 2005 23:03:07 GMT (envelope-from anholt) Date: Thu, 13 Jan 2005 23:03:07 GMT From: Eric Anholt Message-Id: <200501132303.j0DN37Tp039852@freefall.freebsd.org> To: rafan@infor.org, anholt@FreeBSD.org, freebsd-x11@FreeBSD.org Subject: Re: ports/74981: [PATCH] x11/xorg-clients: luit has synchronization problem with tty setting X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 23:03:08 -0000 Synopsis: [PATCH] x11/xorg-clients: luit has synchronization problem with tty setting State-Changed-From-To: open->patched State-Changed-By: anholt State-Changed-When: Thu Jan 13 23:02:52 GMT 2005 State-Changed-Why: Fixed in xorg-clients, leaving open for lesi@ to pick up for XFree86. http://www.freebsd.org/cgi/query-pr.cgi?pr=74981 From owner-freebsd-x11@FreeBSD.ORG Fri Jan 14 16:28:00 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0FA116A4CE for ; Fri, 14 Jan 2005 16:28:00 +0000 (GMT) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2738243D4C for ; Fri, 14 Jan 2005 16:27:59 +0000 (GMT) (envelope-from oliver@FreeBSD.org) Received: (qmail 56726 invoked by uid 89); 14 Jan 2005 16:26:30 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 14 Jan 2005 16:26:30 -0000 Date: Fri, 14 Jan 2005 17:28:24 +0100 From: Oliver Lehmann To: Eric Anholt Message-Id: <20050114172824.67139826.oliver@FreeBSD.org> In-Reply-To: <200501132054.j0DKsIqQ023076@freefall.freebsd.org> References: <200501132054.j0DKsIqQ023076@freefall.freebsd.org> X-Mailer: Sylpheed version 1.0.0-gtk2-20041224 (GTK+ 2.4.14; i386-portbld-freebsd5.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: anholt@FreeBSD.org cc: freebsd-x11@FreeBSD.org cc: oliver@freebsd.org Subject: Re: ports/75666: add Matrox MGA Driver to xorg-server X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 16:28:00 -0000 Eric Anholt wrote: > Synopsis: add Matrox MGA Driver to xorg-server > > State-Changed-From-To: open->closed > State-Changed-By: anholt > State-Changed-When: Thu Jan 13 20:52:48 GMT 2005 > State-Changed-Why: > I've committed an mga_hal port in x11-servers which I believe does all > that's necessary for MGA HAL support, without cluttering up xorg-server. > (I read the > diffs and didn't see things that seemed too major, but please tell me if > there are pieces of Matrox's code that are necessary). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=75666 Would be nice to get the mga_drv.o module installed too since there is a noteable performance plus by using that file instead of the one which gets compiled from xorg (at least on my Cel500) -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-x11@FreeBSD.ORG Fri Jan 14 20:47:39 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60F4616A4CE; Fri, 14 Jan 2005 20:47:39 +0000 (GMT) Received: from leguin.anholt.net (69-30-77-85.dq1sn.easystreet.com [69.30.77.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id C284043D1D; Fri, 14 Jan 2005 20:47:38 +0000 (GMT) (envelope-from anholt@FreeBSD.org) Received: from leguin.anholt.net (localhost [127.0.0.1]) by leguin.anholt.net (8.13.1/8.13.1) with ESMTP id j0EKlXrP000981; Fri, 14 Jan 2005 12:47:33 -0800 (PST) (envelope-from anholt@FreeBSD.org) Received: (from anholt@localhost) by leguin.anholt.net (8.13.1/8.13.1/Submit) id j0EKlXj7000980; Fri, 14 Jan 2005 12:47:33 -0800 (PST) (envelope-from anholt@FreeBSD.org) X-Authentication-Warning: leguin.anholt.net: anholt set sender to anholt@FreeBSD.org using -f From: Eric Anholt To: Oliver Lehmann In-Reply-To: <20050114172824.67139826.oliver@FreeBSD.org> References: <200501132054.j0DKsIqQ023076@freefall.freebsd.org> <20050114172824.67139826.oliver@FreeBSD.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 14 Jan 2005 12:47:32 -0800 Message-Id: <1105735652.846.3.camel@leguin> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 FreeBSD GNOME Team Port cc: freebsd-x11@FreeBSD.org Subject: Re: ports/75666: add Matrox MGA Driver to xorg-server X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: eta@lclark.edu List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 20:47:39 -0000 On Fri, 2005-01-14 at 17:28 +0100, Oliver Lehmann wrote: > Eric Anholt wrote: > > > Synopsis: add Matrox MGA Driver to xorg-server > > > > State-Changed-From-To: open->closed > > State-Changed-By: anholt > > State-Changed-When: Thu Jan 13 20:52:48 GMT 2005 > > State-Changed-Why: > > I've committed an mga_hal port in x11-servers which I believe does all > > that's necessary for MGA HAL support, without cluttering up xorg-server. > > (I read the > > diffs and didn't see things that seemed too major, but please tell me if > > there are pieces of Matrox's code that are necessary). > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=75666 > > Would be nice to get the mga_drv.o module installed too since there is a > noteable performance plus by using that file instead of the one which gets > compiled from xorg (at least on my Cel500) What would be even nicer is figuring out which of the hunks of Matrox's patch would cause a performance improvement, so it can get integrated upstream and everyone can benefit without having to do an mess like the nvidia driver that gets broken on a regular basis. The diff is pretty small if you do diff -bu -- Eric Anholt eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org From owner-freebsd-x11@FreeBSD.ORG Fri Jan 14 23:44:24 2005 Return-Path: Delivered-To: freebsd-x11@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A82A16A4CF; Fri, 14 Jan 2005 23:44:24 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B03443D1D; Fri, 14 Jan 2005 23:44:24 +0000 (GMT) (envelope-from lesi@FreeBSD.org) Received: from freefall.freebsd.org (lesi@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j0ENiO3U067305; Fri, 14 Jan 2005 23:44:24 GMT (envelope-from lesi@freefall.freebsd.org) Received: (from lesi@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j0ENiNvV067300; Fri, 14 Jan 2005 23:44:23 GMT (envelope-from lesi) Date: Fri, 14 Jan 2005 23:44:23 GMT From: Dejan Lesjak Message-Id: <200501142344.j0ENiNvV067300@freefall.freebsd.org> To: rafan@infor.org, lesi@FreeBSD.org, freebsd-x11@FreeBSD.org Subject: Re: ports/74981: [PATCH] x11/xorg-clients: luit has synchronization problem with tty setting X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 23:44:24 -0000 Synopsis: [PATCH] x11/xorg-clients: luit has synchronization problem with tty setting State-Changed-From-To: patched->closed State-Changed-By: lesi State-Changed-When: Fri Jan 14 23:43:37 GMT 2005 State-Changed-Why: Fixed also in XFree86-4-clients. Thanks for report. http://www.freebsd.org/cgi/query-pr.cgi?pr=74981 From owner-freebsd-x11@FreeBSD.ORG Sat Jan 15 05:00:14 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC04916A4CE for ; Sat, 15 Jan 2005 05:00:14 +0000 (GMT) Received: from mail4.hsphere.cc (mail4.hsphere.cc [216.157.145.24]) by mx1.FreeBSD.org (Postfix) with SMTP id 0FDEE43D41 for ; Sat, 15 Jan 2005 05:00:14 +0000 (GMT) (envelope-from acardenas@bsdperu.org) Received: (qmail 90237 invoked by uid 399); 15 Jan 2005 05:00:13 -0000 Received: from unknown (HELO ?200.121.31.131?) (acardenas@bsdperu.org@200.121.31.131) by mail4.hsphere.cc with (DHE-RSA-AES256-SHA encrypted) SMTP; 15 Jan 2005 05:00:13 -0000 Message-ID: <41E8A34F.8020108@bsdperu.org> Date: Fri, 14 Jan 2005 23:59:59 -0500 From: Jose Alonso Cardenas Marquez User-Agent: Mozilla Thunderbird 1.0 (X11/20041228) X-Accept-Language: en-us, en MIME-Version: 1.0 To: x11@FreeBSD.org, freebsd-x11@FreeBSD.org X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------030703050407090008000307" Subject: [Fwd: Re: i386/76257: xorg-clients 6.8.1_1 ports problems] X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2005 05:00:14 -0000 This is a multi-part message in MIME format. --------------030703050407090008000307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Forward PR about xorg-clients problems Greetings ACMhUnTeR --------------030703050407090008000307 Content-Type: message/rfc822; name="Re: i386/76257: xorg-clients 6.8.1_1 ports problems" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Re: i386/76257: xorg-clients 6.8.1_1 ports problems" X-Account-Key: account3 Return-Path: Delivered-To: acardenas@bsdperu.org Received: (qmail 84314 invoked by uid 399); 14 Jan 2005 23:10:32 -0000 Received: from unknown (HELO mx2.freebsd.org) (216.136.204.119) by mail4.hsphere.cc with SMTP; 14 Jan 2005 23:10:31 -0000 Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 5BB5A55BD9 for ; Fri, 14 Jan 2005 23:10:31 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2168016A4CF for ; Fri, 14 Jan 2005 23:10:31 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 264AB43D39 for ; Fri, 14 Jan 2005 23:10:09 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j0ENA998065020 for ; Fri, 14 Jan 2005 23:10:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j0ENA9aY065017; Fri, 14 Jan 2005 23:10:09 GMT (envelope-from gnats) Date: Fri, 14 Jan 2005 23:10:09 GMT Message-Id: <200501142310.j0ENA9aY065017@freefall.freebsd.org> To: Jose Alonso Cardenas Marquez From: FreeBSD-gnats-submit@FreeBSD.org Subject: Re: i386/76257: xorg-clients 6.8.1_1 ports problems Reply-To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-i386@FreeBSD.org In-Reply-To: Your message of Fri, 14 Jan 2005 23:02:57 GMT <200501142302.j0EN2vsv010183@www.freebsd.org> Thank you very much for your problem report. It has the internal identification `i386/76257'. The individual assigned to look at your report is: freebsd-i386. You can access the state of your problem report at any time via this link: http://www.freebsd.org/cgi/query-pr.cgi?pr=76257 >Category: i386 >Responsible: freebsd-i386 >Synopsis: xorg-clients 6.8.1_1 ports problems >Arrival-Date: Fri Jan 14 23:10:08 GMT 2005 --------------030703050407090008000307-- From owner-freebsd-x11@FreeBSD.ORG Sat Jan 15 05:00:14 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B2A1016A4CF for ; Sat, 15 Jan 2005 05:00:14 +0000 (GMT) Received: from mail4.hsphere.cc (mail4.hsphere.cc [216.157.145.24]) by mx1.FreeBSD.org (Postfix) with SMTP id 0FC8543D39 for ; Sat, 15 Jan 2005 05:00:14 +0000 (GMT) (envelope-from acardenas@bsdperu.org) Received: (qmail 90237 invoked by uid 399); 15 Jan 2005 05:00:13 -0000 Received: from unknown (HELO ?200.121.31.131?) (acardenas@bsdperu.org@200.121.31.131) by mail4.hsphere.cc with (DHE-RSA-AES256-SHA encrypted) SMTP; 15 Jan 2005 05:00:13 -0000 Message-ID: <41E8A34F.8020108@bsdperu.org> Date: Fri, 14 Jan 2005 23:59:59 -0500 From: Jose Alonso Cardenas Marquez User-Agent: Mozilla Thunderbird 1.0 (X11/20041228) X-Accept-Language: en-us, en MIME-Version: 1.0 To: x11@FreeBSD.org, freebsd-x11@FreeBSD.org X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------030703050407090008000307" Subject: [Fwd: Re: i386/76257: xorg-clients 6.8.1_1 ports problems] X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2005 05:00:14 -0000 This is a multi-part message in MIME format. --------------030703050407090008000307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Forward PR about xorg-clients problems Greetings ACMhUnTeR --------------030703050407090008000307 Content-Type: message/rfc822; name="Re: i386/76257: xorg-clients 6.8.1_1 ports problems" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Re: i386/76257: xorg-clients 6.8.1_1 ports problems" X-Account-Key: account3 Return-Path: Delivered-To: acardenas@bsdperu.org Received: (qmail 84314 invoked by uid 399); 14 Jan 2005 23:10:32 -0000 Received: from unknown (HELO mx2.freebsd.org) (216.136.204.119) by mail4.hsphere.cc with SMTP; 14 Jan 2005 23:10:31 -0000 Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 5BB5A55BD9 for ; Fri, 14 Jan 2005 23:10:31 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2168016A4CF for ; Fri, 14 Jan 2005 23:10:31 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 264AB43D39 for ; Fri, 14 Jan 2005 23:10:09 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j0ENA998065020 for ; Fri, 14 Jan 2005 23:10:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j0ENA9aY065017; Fri, 14 Jan 2005 23:10:09 GMT (envelope-from gnats) Date: Fri, 14 Jan 2005 23:10:09 GMT Message-Id: <200501142310.j0ENA9aY065017@freefall.freebsd.org> To: Jose Alonso Cardenas Marquez From: FreeBSD-gnats-submit@FreeBSD.org Subject: Re: i386/76257: xorg-clients 6.8.1_1 ports problems Reply-To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-i386@FreeBSD.org In-Reply-To: Your message of Fri, 14 Jan 2005 23:02:57 GMT <200501142302.j0EN2vsv010183@www.freebsd.org> Thank you very much for your problem report. It has the internal identification `i386/76257'. The individual assigned to look at your report is: freebsd-i386. You can access the state of your problem report at any time via this link: http://www.freebsd.org/cgi/query-pr.cgi?pr=76257 >Category: i386 >Responsible: freebsd-i386 >Synopsis: xorg-clients 6.8.1_1 ports problems >Arrival-Date: Fri Jan 14 23:10:08 GMT 2005 --------------030703050407090008000307-- From owner-freebsd-x11@FreeBSD.ORG Sat Jan 15 11:16:39 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1CAEF16A4CE; Sat, 15 Jan 2005 11:16:39 +0000 (GMT) Received: from niobe.ijs.si (mail.ijs.si [193.2.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2801A43D41; Sat, 15 Jan 2005 11:16:38 +0000 (GMT) (envelope-from dejan.lesjak@ijs.si) Received: from localhost (localhost.ijs.si [127.0.0.1]) by niobe.ijs.si (Postfix) with ESMTP id EC6F61DD461; Sat, 15 Jan 2005 12:16:36 +0100 (CET) Received: from niobe.ijs.si ([127.0.0.1]) by localhost (niobe.ijs.si [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12884-16; Sat, 15 Jan 2005 12:16:35 +0100 (CET) Received: from metatron.ijs.si (metatron.ijs.si [193.2.4.152]) by niobe.ijs.si (Postfix) with ESMTP id EFC0A1DD46A; Sat, 15 Jan 2005 12:16:34 +0100 (CET) Received: from idefix.ijs.si (idefix.ijs.si [193.2.4.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by metatron.ijs.si (Postfix) with ESMTP id 8AC7D1C00738; Sat, 15 Jan 2005 12:16:34 +0100 (CET) From: Dejan Lesjak To: freebsd-x11@freebsd.org Date: Sat, 15 Jan 2005 12:16:33 +0100 User-Agent: KMail/1.7.2 References: <20050104092619.GA787@straylight.m.ringlet.net> <20050104093017.GA1048@straylight.m.ringlet.net> In-Reply-To: <20050104093017.GA1048@straylight.m.ringlet.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200501151216.33792.dejan.lesjak@ijs.si> X-Virus-Scanned: amavisd-new at ijs.si cc: x11@freebsd.org cc: Peter Pentchev cc: freebsd-ports@freebsd.org Subject: Re: [PATCH] X.org/XFree86 DEPENDS_TARGET X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2005 11:16:39 -0000 On Tuesday 04 of January 2005 10:30, Peter Pentchev wrote: > On Tue, Jan 04, 2005 at 11:26:19AM +0200, Peter Pentchev wrote: > > Hi, > > > > Maybe I should have spoken up earlier, since I've been running with > > this little patch for pretty much a year now, but still, better late > > than never, I guess :) > > Whoops. I certainly meant to CC this to -ports. > > > Currently, both x11/xorg and x11/XFree86-4 redefine the DEPENDS_TARGET > > when a package is requested. What do y'all think about the following > > trivial patch that makes it only override DEPENDS_TARGET if it does not > > already contain a 'package' target? I always build all ports with a > > DEPENDS_TARGET='install package clean', which helps a lot, especially > > with the X.org/XFree86 metaports ;) [snip] > > -.if make(package) > > +.if make(package) && ${DEPENDS_TARGET:Mpackage} == "" This doesn't seem to work if DEPENDS_TARGET is not defined, the following line however does: .if make(package) && empty(${DEPENDS_TARGET:Mpackage}) Does this still work in your case as expected? Dejan From owner-freebsd-x11@FreeBSD.ORG Sat Jan 15 11:16:39 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1CAEF16A4CE; Sat, 15 Jan 2005 11:16:39 +0000 (GMT) Received: from niobe.ijs.si (mail.ijs.si [193.2.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2801A43D41; Sat, 15 Jan 2005 11:16:38 +0000 (GMT) (envelope-from dejan.lesjak@ijs.si) Received: from localhost (localhost.ijs.si [127.0.0.1]) by niobe.ijs.si (Postfix) with ESMTP id EC6F61DD461; Sat, 15 Jan 2005 12:16:36 +0100 (CET) Received: from niobe.ijs.si ([127.0.0.1]) by localhost (niobe.ijs.si [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12884-16; Sat, 15 Jan 2005 12:16:35 +0100 (CET) Received: from metatron.ijs.si (metatron.ijs.si [193.2.4.152]) by niobe.ijs.si (Postfix) with ESMTP id EFC0A1DD46A; Sat, 15 Jan 2005 12:16:34 +0100 (CET) Received: from idefix.ijs.si (idefix.ijs.si [193.2.4.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by metatron.ijs.si (Postfix) with ESMTP id 8AC7D1C00738; Sat, 15 Jan 2005 12:16:34 +0100 (CET) From: Dejan Lesjak To: freebsd-x11@freebsd.org Date: Sat, 15 Jan 2005 12:16:33 +0100 User-Agent: KMail/1.7.2 References: <20050104092619.GA787@straylight.m.ringlet.net> <20050104093017.GA1048@straylight.m.ringlet.net> In-Reply-To: <20050104093017.GA1048@straylight.m.ringlet.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200501151216.33792.dejan.lesjak@ijs.si> X-Virus-Scanned: amavisd-new at ijs.si cc: x11@freebsd.org cc: Peter Pentchev cc: freebsd-ports@freebsd.org Subject: Re: [PATCH] X.org/XFree86 DEPENDS_TARGET X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2005 11:16:39 -0000 On Tuesday 04 of January 2005 10:30, Peter Pentchev wrote: > On Tue, Jan 04, 2005 at 11:26:19AM +0200, Peter Pentchev wrote: > > Hi, > > > > Maybe I should have spoken up earlier, since I've been running with > > this little patch for pretty much a year now, but still, better late > > than never, I guess :) > > Whoops. I certainly meant to CC this to -ports. > > > Currently, both x11/xorg and x11/XFree86-4 redefine the DEPENDS_TARGET > > when a package is requested. What do y'all think about the following > > trivial patch that makes it only override DEPENDS_TARGET if it does not > > already contain a 'package' target? I always build all ports with a > > DEPENDS_TARGET='install package clean', which helps a lot, especially > > with the X.org/XFree86 metaports ;) [snip] > > -.if make(package) > > +.if make(package) && ${DEPENDS_TARGET:Mpackage} == "" This doesn't seem to work if DEPENDS_TARGET is not defined, the following line however does: .if make(package) && empty(${DEPENDS_TARGET:Mpackage}) Does this still work in your case as expected? Dejan From owner-freebsd-x11@FreeBSD.ORG Sat Jan 15 11:47:06 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 022CD16A4CF for ; Sat, 15 Jan 2005 11:47:06 +0000 (GMT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 4BC3E43D31 for ; Sat, 15 Jan 2005 11:47:04 +0000 (GMT) (envelope-from roam@ringlet.net) Received: (qmail 3400 invoked from network); 15 Jan 2005 11:46:59 -0000 Received: from unknown (HELO straylight.ringlet.net) (213.16.36.109) by gandalf.online.bg with SMTP; 15 Jan 2005 11:46:59 -0000 Received: (qmail 4169 invoked by uid 1000); 15 Jan 2005 11:47:01 -0000 Date: Sat, 15 Jan 2005 13:47:00 +0200 From: Peter Pentchev To: Dejan Lesjak Message-ID: <20050115114700.GA784@straylight.m.ringlet.net> Mail-Followup-To: Dejan Lesjak , freebsd-x11@freebsd.org, freebsd-ports@freebsd.org References: <20050104092619.GA787@straylight.m.ringlet.net> <20050104093017.GA1048@straylight.m.ringlet.net> <200501151216.33792.dejan.lesjak@ijs.si> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5vNYLRcllDrimb99" Content-Disposition: inline In-Reply-To: <200501151216.33792.dejan.lesjak@ijs.si> User-Agent: Mutt/1.5.6i cc: freebsd-x11@freebsd.org cc: freebsd-ports@freebsd.org Subject: Re: [PATCH] X.org/XFree86 DEPENDS_TARGET X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2005 11:47:06 -0000 --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 15, 2005 at 12:16:33PM +0100, Dejan Lesjak wrote: > On Tuesday 04 of January 2005 10:30, Peter Pentchev wrote: > > On Tue, Jan 04, 2005 at 11:26:19AM +0200, Peter Pentchev wrote: > > > Hi, > > > > > > Maybe I should have spoken up earlier, since I've been running with > > > this little patch for pretty much a year now, but still, better late > > > than never, I guess :) > > > > Whoops. I certainly meant to CC this to -ports. > > > > > Currently, both x11/xorg and x11/XFree86-4 redefine the DEPENDS_TARGET > > > when a package is requested. What do y'all think about the following > > > trivial patch that makes it only override DEPENDS_TARGET if it does n= ot > > > already contain a 'package' target? I always build all ports with a > > > DEPENDS_TARGET=3D'install package clean', which helps a lot, especial= ly > > > with the X.org/XFree86 metaports ;) > [snip] > > > -.if make(package) > > > +.if make(package) && ${DEPENDS_TARGET:Mpackage} =3D=3D "" >=20 > This doesn't seem to work if DEPENDS_TARGET is not defined, Good catch, thanks! =09 > the following line however does: >=20 > .if make(package) && empty(${DEPENDS_TARGET:Mpackage}) I think you mean empty(DEPENDS_TARGET:Mpackage) here, without the ${}, or it would always test the wrong variable for emptiness. > Does this still work in your case as expected? Yes, the following patch works for me. Thanks a lot! Index: ports/x11/XFree86-4/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/ports/x11/XFree86-4/Makefile,v retrieving revision 1.160 diff -u -r1.160 Makefile --- ports/x11/XFree86-4/Makefile 23 Dec 2004 01:35:41 -0000 1.160 +++ ports/x11/XFree86-4/Makefile 15 Jan 2005 11:43:34 -0000 @@ -48,7 +48,7 @@ @${ECHO_MSG} "upgrade XFree86. If you simply type 'make install' it may = use over 2GB to build" @${ECHO_MSG} "all of the subports. You can install the ports singly if y= ou are low on space." =20 -.if make(package) +.if make(package) && empty(DEPENDS_TARGET:Mpackage) DEPENDS_TARGET=3D"package" .endif .undef NOCLEANDEPENDS Index: ports/x11/xorg/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/ports/x11/xorg/Makefile,v retrieving revision 1.9 diff -u -r1.9 Makefile --- ports/x11/xorg/Makefile 23 Dec 2004 01:35:42 -0000 1.9 +++ ports/x11/xorg/Makefile 15 Jan 2005 11:44:31 -0000 @@ -55,7 +55,7 @@ @${ECHO_MSG} "upgrade X.Org. If you simply type 'make install' it may us= e over 2GB to build" @${ECHO_MSG} "all of the subports. You can install the ports singly if y= ou are low on space." =20 -.if make(package) +.if make(package) && empty(DEPENDS_TARGET:Mpackage) DEPENDS_TARGET=3D"package" .endif =20 G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I've heard that this sentence is a rumor. --5vNYLRcllDrimb99 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFB6QK07Ri2jRYZRVMRAnfqAKC3lry4doEletVW7V7IfF8fWB4dSQCeJq74 n4moXHYNr3T6EbPCajZJaag= =1jhC -----END PGP SIGNATURE----- --5vNYLRcllDrimb99-- From owner-freebsd-x11@FreeBSD.ORG Sat Jan 15 13:07:29 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2AA3616A4CE for ; Sat, 15 Jan 2005 13:07:29 +0000 (GMT) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 368F243D48 for ; Sat, 15 Jan 2005 13:07:28 +0000 (GMT) (envelope-from oliver@FreeBSD.org) Received: (qmail 83787 invoked by uid 89); 15 Jan 2005 13:05:59 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 15 Jan 2005 13:05:59 -0000 Date: Sat, 15 Jan 2005 14:07:54 +0100 From: Oliver Lehmann To: eta@lclark.edu Message-Id: <20050115140754.78e2fc7d.oliver@FreeBSD.org> In-Reply-To: <1105735652.846.3.camel@leguin> References: <200501132054.j0DKsIqQ023076@freefall.freebsd.org> <20050114172824.67139826.oliver@FreeBSD.org> <1105735652.846.3.camel@leguin> X-Mailer: Sylpheed version 1.0.0-gtk2-20041224 (GTK+ 2.4.14; i386-portbld-freebsd5.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: anholt@FreeBSD.org cc: freebsd-x11@FreeBSD.org Subject: Re: ports/75666: add Matrox MGA Driver to xorg-server X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2005 13:07:29 -0000 Eric Anholt wrote: > What would be even nicer is figuring out which of the hunks of Matrox's > patch would cause a performance improvement, so it can get integrated > upstream and everyone can benefit without having to do an mess like the > nvidia driver that gets broken on a regular basis. The diff is pretty > small if you do diff -bu I think that the same licence which prevents the x-team for merging the stuff matrox provides back into their source, would prevent modifying the xorg mga driver in any other way based on the matrox sources. -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/