CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/11/03 06:47:29 Log message: remove CENTER STRETCH options that were never implemented. Modified files: xc/programs/Xserver/hw/xfree86/drivers/i810/: i830_driver.c Revision ChangesPath 1.47 +2 -6 xc/programs/Xserver/hw/xfree86/drivers/i810/i830_driver.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/11/03 09:02:55 Log message: SiS driver: - Allow simultanious SVIDEO + COMPOSITE TV output - Fix HW Cursor on CRT1 in MergedFB mode (work around a hw bug) - Clean up Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: 300vtbl.h 310vtbl.h init.c init301.c sis.h sis300_accel.h sis310_accel.c sis_accel.c sis_accel.h sis_cursor.c sis_dac.c sis_driver.c sis_opt.c sis_setup.c sis_vga.c sis_video.c vstruct.h Revision ChangesPath 1.19 +2 -2 xc/programs/Xserver/hw/xfree86/drivers/sis/300vtbl.h 1.19 +3 -3 xc/programs/Xserver/hw/xfree86/drivers/sis/310vtbl.h 1.32 +7 -13 xc/programs/Xserver/hw/xfree86/drivers/sis/init.c 1.46 +2 -2 xc/programs/Xserver/hw/xfree86/drivers/sis/init301.c 1.82 +2 -2 xc/programs/Xserver/hw/xfree86/drivers/sis/sis.h 1.16 +1 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/sis300_accel.h 1.31 +1 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/sis310_accel.c 1.34 +1 -2 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_accel.c 1.9 +1 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_accel.h 1.22 +4 -0 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_cursor.c 1.46 +6 -6 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_dac.c 1.150 +10 -12xc/programs/Xserver/hw/xfree86/drivers/sis/sis_driver.c 1.42 +8 -2 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_opt.c 1.23 +2 -2 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_setup.c 1.35 +1 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_vga.c 1.36 +4 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_video.c 1.22 +2 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/vstruct.h ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/11/03 10:05:10 Log message: SiS driver: - Merge one more IRIX build fix I had missed when importing Marc's changes Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: init.c sis_driver.c Revision ChangesPath 1.33 +9 -2 xc/programs/Xserver/hw/xfree86/drivers/sis/init.c 1.151 +2 -2 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_driver.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/11/03 14:19:35 Log message: Usused variables Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: init301.c sis_vga.c Revision ChangesPath 1.47 +2 -3 xc/programs/Xserver/hw/xfree86/drivers/sis/init301.c 1.36 +1 -5 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_vga.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/11/03 14:17:22 Log message: Typo Modified files: xc/programs/Xserver/hw/xfree86/drivers/glint/: glint_driver.c Revision ChangesPath 1.163 +2 -2 xc/programs/Xserver/hw/xfree86/drivers/glint/glint_driver.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/11/03 16:24:36 Log message: Fix building libOSMesa on Darwin. Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG xc/lib/GL/mesa/src/OSmesa/: Imakefile xc/config/cf/: darwinLib.tmpl Revision ChangesPath 3.2932+2 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG 1.19 +4 -2 xc/lib/GL/mesa/src/OSmesa/Imakefile 1.19 +2 -1 xc/config/cf/darwinLib.tmpl ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/11/03 17:25:32 Log message: Workaround libGLU build problem with default gcc installation on Solaris/x86. Modified files: xc/config/cf/: Imake.tmpl sv4Lib.tmpl svr4.cf Revision ChangesPath 3.153 +12 -1 xc/config/cf/Imake.tmpl 3.8 +2 -2 xc/config/cf/sv4Lib.tmpl 3.50 +7 -1 xc/config/cf/svr4.cf ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/11/03 17:57:21 Log message: FreeBSD 3.x and earlier doesn't have IPv6, although AF_INET6 is defined. Modified files: xc/config/cf/: FreeBSD.cf Revision ChangesPath 3.139 +8 -1 xc/config/cf/FreeBSD.cf ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/11/03 17:59:32 Log message: - put CplusplusLibC in Imake.tmpl together - remove redundant CplusplusLibC defns in *Lib.tmpl Modified files: xc/config/cf/: Imake.tmpl bsdLib.tmpl bsdiLib.tmpl gnuLib.tmpl lnxLib.tmpl Revision ChangesPath 3.154 +5 -6 xc/config/cf/Imake.tmpl 3.23 +1 -3 xc/config/cf/bsdLib.tmpl 3.4 +1 -2 xc/config/cf/bsdiLib.tmpl 1.6 +1 -3 xc/config/cf/gnuLib.tmpl 3.20 +1 -3 xc/config/cf/lnxLib.tmpl ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/11/03 18:47:38 Log message: Fix start up failure on Panther due to bad keymapping file load. Modified files: xc/programs/Xserver/hw/darwin/: darwin.c Revision ChangesPath 1.54 +10 -7 xc/programs/Xserver/hw/darwin/darwin.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/11/03 18:52:53 Log message: Fix spurious #pragma getting inserted into scripts and man pages on Panther due to rogue cpp-3.3 preprocessor (Martin Costabel). Modified files: xc/config/cf/: darwin.cf Revision ChangesPath 1.42 +11 -3 xc/config/cf/darwin.cf ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
Nvidia driver relation to XFree
I'm working on a kernel debugger which is similar to SoftICE on WIndows. I would like to take advantage of the graphics mode when a user activates the debugger under X and so I was investigating how to solve this. When I use normal VGA mode it doesn't work on my card when I have X running while a fellow coder has a similar card with also nvidia drvier and it works for him (more or less). Now I wonder what is the relation of the video driver to X. What is happening when i.e. the user changes to a console? X must save the current state of the VGA card (i.e. resolution, frequency, etc.) and switch to a suitable console mode. Similarily when the user switches back to X this has to be reversed and the state restored. Now I wonder how exactly this is going to happen. Since nvidia doesn't open it's code I can't look at it, but there has to be some interface so that X can do this stuff without knowing the details of the driver. Can I use this interface in kernel modules as well? I think it should be possible. Another thing is, that I would like to take advantage of the current display and draw my window directly into the framebuffer. Is this possible? I know that I can install the framebuffer support for the kernel and then I would have an interface to do this, but I wonder how X is doing that. Can I get the pointer to the framebuffer and use it, or is there some way to do this via an interface through the driver. It is not exaclty clear to me on how X and nvidia.o are related to each other. Of course the same holds true for other cards, so the best solution for my purpose would be to find some way that is more or less independent of the card, but I guess this is to much to ask for. :) -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Nvidia driver relation to XFree
On Mon, 2003-11-03 at 16:51, Gerhard W. Gruber wrote: I'm working on a kernel debugger which is similar to SoftICE on WIndows. I would like to take advantage of the graphics mode when a user activates the debugger under X and so I was investigating how to solve this. When I use normal VGA mode it doesn't work on my card when I have X running while a fellow coder has a similar card with also nvidia drvier and it works for him (more or less). Now I wonder what is the relation of the video driver to X. What is happening when i.e. the user changes to a console? X must save the current state of the VGA card (i.e. resolution, frequency, etc.) and switch to a suitable console mode. Similarily when the user switches back to X this has to be reversed and the state restored. Now I wonder how exactly this is going to happen. Since nvidia doesn't open it's code I can't look at it, but there has to be some interface so that X can do this stuff without knowing the details of the driver. Can I use this interface in kernel modules as well? I think it should be possible. You would probably need to use an XFree86 extension. Look at the DGA extension. -- Torgeir Veimo [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Nvidia driver relation to XFree
On Mon, 03 Nov 2003 17:51:53 +0100, Gerhard W. Gruber wrote: I'm working on a kernel debugger which is similar to SoftICE on WIndows. I would like to take advantage of the graphics mode when a user activates the debugger under X and so I was investigating how to solve this. When I use normal VGA mode it doesn't work on my card when I have X running while a fellow coder has a similar card with also nvidia drvier and it works for him (more or less). Now I wonder what is the relation of the video driver to X. The video driver is part of XFree86. What is happening when i.e. the user changes to a console? X must save the current state of the VGA card (i.e. resolution, frequency, etc.) and switch to a suitable console mode. Basically, yes. It isn't usually necessary to save the graphics state; the driver put the card in a graphics state initially, and since it still knows the parameters requested in the XF86Config file, it can put the card back into that state whenever it wishes. However, the driver does have to save the INITIAL state of the graphics card when the driver starts up so it can restore that before switching back to a console. The console driver does NOT know how to switch back to text mode, so XFree86 must insure that the card is in its original condition before allowing the VT switch to go on. Similarily when the user switches back to X this has to be reversed and the state restored. Now I wonder how exactly this is going to happen. Since nvidia doesn't open it's code I can't look at it, but there has to be some interface so that X can do this stuff without knowing the details of the driver. The driver is part of XFree86. Each driver has functions called EnterVT and LeaveVT (where depends on the driver name) that implement the switch to and from a console (VT = virtual terminal). Go look through some of the drivers and you can see how it is done. Can I use this interface in kernel modules as well? I think it should be possible. Absolutely not. XFree86 drivers are just user-mode shared object files loaded by the XFree86 executable. They use a custom API and call a bunch of user-mode functions. They will not work in kernel mode. Another thing is, that I would like to take advantage of the current display and draw my window directly into the framebuffer. Is this possible? Haven't we had this conversation before? I know that I can install the framebuffer support for the kernel and then I would have an interface to do this, but I wonder how X is doing that. The XFree86 driver has INTIMATE knowledge of the specific graphics card. Typically, the driver goes out and reads the PCI configuration registers (or allows XFree86 to do it) to get the physical addresses assigned to the board. Because the driver knows the card, it knows which of the addresses is the frame buffer and which has the memory-mapped registers. It maps that space into user-mode address space, and starts writing. Can I get the pointer to the framebuffer and use it, or is there some way to do this via an interface through the driver. It is not exaclty clear to me on how X and nvidia.o are related to each other. nvidia.o is part of XFree86. It is a dynamically-loaded library that implements the same interface as all other XFree86 video drivers, and it calls back in to the XFree86 executable and its other drivers for most of its services. Of course the same holds true for other cards, so the best solution for my purpose would be to find some way that is more or less independent of the card, but I guess this is to much to ask for. :) DGA is one was for you to take ownership of the frame buffer, but like all of XFree86, it is a user-mode service. -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Nvidia driver relation to XFree
On Mon, 03 Nov 2003 16:58:10 +, Torgeir Veimo [EMAIL PROTECTED] wrote: You would probably need to use an XFree86 extension. Look at the DGA extension. I don't want to use X itself. I need to use this functionality from within a kernel module, so I don't want to rely on a user space application. I just want to know what is happening inside X to see if I can use at least some of it for my project. -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: Nvidia driver relation to XFree
one way to do what you want (from kernel space) is to use the kernel framebuffer driver for writing graphics, and use up one of the VT's for your debugger, switching to that vt when doing, umm, whatever your doing I have to ask tho, whats wrong with kgdb? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Tim Roberts Sent: 03 November 2003 18:09 To: [EMAIL PROTECTED] Subject: Re: Nvidia driver relation to XFree On Mon, 03 Nov 2003 17:51:53 +0100, Gerhard W. Gruber wrote: I'm working on a kernel debugger which is similar to SoftICE on WIndows. I would like to take advantage of the graphics mode when a user activates the debugger under X and so I was investigating how to solve this. When I use normal VGA mode it doesn't work on my card when I have X running while a fellow coder has a similar card with also nvidia drvier and it works for him (more or less). Now I wonder what is the relation of the video driver to X. The video driver is part of XFree86. What is happening when i.e. the user changes to a console? X must save the current state of the VGA card (i.e. resolution, frequency, etc.) and switch to a suitable console mode. Basically, yes. It isn't usually necessary to save the graphics state; the driver put the card in a graphics state initially, and since it still knows the parameters requested in the XF86Config file, it can put the card back into that state whenever it wishes. However, the driver does have to save the INITIAL state of the graphics card when the driver starts up so it can restore that before switching back to a console. The console driver does NOT know how to switch back to text mode, so XFree86 must insure that the card is in its original condition before allowing the VT switch to go on. Similarily when the user switches back to X this has to be reversed and the state restored. Now I wonder how exactly this is going to happen. Since nvidia doesn't open it's code I can't look at it, but there has to be some interface so that X can do this stuff without knowing the details of the driver. The driver is part of XFree86. Each driver has functions called EnterVT and LeaveVT (where depends on the driver name) that implement the switch to and from a console (VT = virtual terminal). Go look through some of the drivers and you can see how it is done. Can I use this interface in kernel modules as well? I think it should be possible. Absolutely not. XFree86 drivers are just user-mode shared object files loaded by the XFree86 executable. They use a custom API and call a bunch of user-mode functions. They will not work in kernel mode. Another thing is, that I would like to take advantage of the current display and draw my window directly into the framebuffer. Is this possible? Haven't we had this conversation before? I know that I can install the framebuffer support for the kernel and then I would have an interface to do this, but I wonder how X is doing that. The XFree86 driver has INTIMATE knowledge of the specific graphics card. Typically, the driver goes out and reads the PCI configuration registers (or allows XFree86 to do it) to get the physical addresses assigned to the board. Because the driver knows the card, it knows which of the addresses is the frame buffer and which has the memory-mapped registers. It maps that space into user-mode address space, and starts writing. Can I get the pointer to the framebuffer and use it, or is there some way to do this via an interface through the driver. It is not exaclty clear to me on how X and nvidia.o are related to each other. nvidia.o is part of XFree86. It is a dynamically-loaded library that implements the same interface as all other XFree86 video drivers, and it calls back in to the XFree86 executable and its other drivers for most of its services. Of course the same holds true for other cards, so the best solution for my purpose would be to find some way that is more or less independent of the card, but I guess this is to much to ask for. :) DGA is one was for you to take ownership of the frame buffer, but like all of XFree86, it is a user-mode service. -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Nvidia driver relation to XFree
On Mon, 03 Nov 2003 10:08:37 -0800, Tim Roberts [EMAIL PROTECTED] wrote: The video driver is part of XFree86. I don't think that this is neccessarily true, or is it? I don'tknow how it is for other cards but in case of NVidia you have this kernel module nvidia.o which you need to load and in the Device section I specify as driver nvidia. Of course it could be that this is just a name which coincides with the kernel module name. I assumed that it is the name of the module that is the driver, but I realize that this is not neccessarily so. Do you mean that this driver also has some part within X itself? It owuld make sense I guess. But then where is this particular module? Is this also some closed source stuff from nVidia? At least I only had to download the kernel module and nothing else because Suse is not allowed to bundle it with their distribution. I suppose, that this would be true for a module within X as well. Basically, yes. It isn't usually necessary to save the graphics state; the driver put the card in a graphics state initially, and since it still knows the parameters requested in the XF86Config file, it can put the card back into that state whenever it wishes. However, the driver does have to Well, at least it needs to know which mode it was, because I can configure several modes and the switch shold restore the one that has been active when I switched console. The driver is part of XFree86. Each driver has functions called EnterVT and LeaveVT (where depends on the driver name) that implement the switch to and from a console (VT = virtual terminal). Go look through some of the drivers and you can see how it is done. Is this the name of the driver mentioned in the XF86Config Device section? In my case this would then be called nvidiaLeaveVT? Absolutely not. XFree86 drivers are just user-mode shared object files loaded by the XFree86 executable. They use a custom API and call a bunch of user-mode functions. They will not work in kernel mode. But the call of the EnterVT/LeaveVT has to end up in the kernel module somewhere, so I guess it should be possible to trace that and see what is called. Another thing is, that I would like to take advantage of the current display and draw my window directly into the framebuffer. Is this possible? Haven't we had this conversation before? Well, it could be, because I asked this in several newsgroups. :) I sure never posted it on the XFree mailinglist I think. :) The XFree86 driver has INTIMATE knowledge of the specific graphics card. Typically, the driver goes out and reads the PCI configuration registers (or allows XFree86 to do it) to get the physical addresses assigned to the board. Because the driver knows the card, it knows which of the addresses is the frame buffer and which has the memory-mapped registers. It maps that space into user-mode address space, and starts writing. And where can I find that code, which interacts with the driver? I think this EnterLeaveVT functions are only a small part of this. Is the most of that card dependent stuff in there as well? nvidia.o is part of XFree86. It is a dynamically-loaded library that implements the same interface as all other XFree86 video drivers, and it calls back in to the XFree86 executable and its other drivers for most of its services. Thanks. I see if I can locate this functions and what they do. DGA is one was for you to take ownership of the frame buffer, but like all of XFree86, it is a user-mode service. Where can I find information about this? -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Nvidia driver relation to XFree
On Mon, 03 Nov 2003 19:53:56 +0100, Gerhard W. Gruber wrote: ? On Mon, 03 Nov 2003 10:08:37 -0800, Tim Roberts [EMAIL PROTECTED] wrote: The video driver is part of XFree86. I don't think that this is neccessarily true, or is it? Yes, it is. I don'tknow how it is for other cards but in case of NVidia you have this kernel module nvidia.o which you need to load and in the Device section I specify as driver nvidia. nvidia.o is not a kernel module. It is just a dynamically loaded object file that gets loaded by the XFree86 dynamic loader and called entirely in user mode. It could have been done as an ordinary .so DLL, but the design objective was to have these work regardless of operating system. That's why there is a loader built-in to XFree86. Of course it could be that this is just a name which coincides with the kernel module name. I assumed that it is the name of the module that is the driver, but I realize that this is not neccessarily so. Some drivers DO have kernel modules, to handle the DMA transfers that are necessary for adequate 3D operation. However, kernel drivers are loaded with insmod. If you specify a driver name in the Device section of an XF86Config file, it is NOT a kernel driver. It is a user-mode library. Do you mean that this driver also has some part within X itself? ALL XFree86 graphics drivers are part of XFree86. The interface they use is specified by and used by the XFree86 executable ONLY. Have you never looked at the XFree86 source code? You need to do so. Really. Much of this would be cleared up. It owuld make sense I guess. But then where is this particular module? Is this also some closed source stuff from nVidia? At least I only had to download the kernel module and nothing else because Suse is not allowed to bundle it with their distribution. I suppose, that this would be true for a module within X as well. If the driver lives in /usr/X11R6/lib/modules/drivers and is named in XF86Config, it is NOT a kernel module. It is a dynamic library that is an integral part of XFree86. If you have a kernel module that you load with insmod, there still needs to be an XFree86 board-specific driver that can talk to that kernel driver. Basically, yes. It isn't usually necessary to save the graphics state; the driver put the card in a graphics state initially, and since it still knows the parameters requested in the XF86Config file, it can put the card back into that state whenever it wishes. Well, at least it needs to know which mode it was, because I can configure several modes and the switch shold restore the one that has been active when I switched console. The driver put it into that mode originally. It has a data structure that tells it exactly what timing parameters it set. All it has to do is do that again. The driver is part of XFree86. Each driver has functions called EnterVT and LeaveVT (where depends on the driver name) that implement the switch to and from a console (VT = virtual terminal). Go look through some of the drivers and you can see how it is done. Is this the name of the driver mentioned in the XF86Config Device section? In my case this would then be called nvidiaLeaveVT? Yes, the name of the driver file is in the XF86Config Device section. If you say: Driver nvidia then XFree86 will load /usr/X11R6/lib/modules/drivers/nvidia_drv.o. The name of the EnterVT entry point is up to the driver, but it will usually be based on the driver name, just like you said. But the call of the EnterVT/LeaveVT has to end up in the kernel module somewhere, so I guess it should be possible to trace that and see what is called. NO, NO, NO! EnterVT/LeaveVT do NOT end up in a kernel module! The user-mode driver that is part of XFree86 does ALL of the register manipulation needed to change the video mode in and out of graphics. It's ALL done in the user-mode driver. For those drivers that DO have kernel components, the kernel sections are doing little more than DMA memory management, which cannot be done in user-mode. Register I/O and mode switching is STILL in user mode. ... Because the driver knows the card, it knows which of the addresses is the frame buffer and which has the memory-mapped registers. It maps that space into user-mode address space, and starts writing. And where can I find that code, which interacts with the driver? I think this EnterLeaveVT functions are only a small part of this. Is the most of that card dependent stuff in there as well? It doesn't INTERACT with the driver. It IS the driver. Every driver in the XFree86 source code (which you really need to read) includes EnterVT and LeaveVT entry points, that do whatever needs to be done to switch the board into and out of graphics mode. For many of the drivers, EnterVT and LeaveVT looks the same; they just call into other functions within that driver. DGA is one was for you to take ownership of the frame buffer, but like all of XFree86, it is a
Re: Nvidia driver relation to XFree
Tim Roberts wrote: NO, NO, NO! EnterVT/LeaveVT do NOT end up in a kernel module! The user-mode driver that is part of XFree86 does ALL of the register manipulation needed to change the video mode in and out of graphics. It's ALL done in the user-mode driver. For those drivers that DO have kernel components, the kernel sections are doing little more than DMA memory management, which cannot be done in user-mode. Register I/O and mode switching is STILL in user mode. ... Because the driver knows the card, it knows which of the addresses is the frame buffer and which has the memory-mapped registers. It maps that space into user-mode address space, and starts writing. And where can I find that code, which interacts with the driver? I think this EnterLeaveVT functions are only a small part of this. Is the most of that card dependent stuff in there as well? It doesn't INTERACT with the driver. It IS the driver. Every driver in the XFree86 source code (which you really need to read) includes EnterVT and LeaveVT entry points, that do whatever needs to be done to switch the board into and out of graphics mode. For many of the drivers, EnterVT and LeaveVT looks the same; they just call into other functions within that driver. I think that one more thing to be said here is that the video drivers' Enter/LeaveVT are 1) completely driver private functions, and 2) - more important - not doing everything needed in order to switch to another VT or back to the server. Leave/EnterVT (with root entry points in one of the top level structures, ScrnInfo) are possibly a cascade of functions which are called one after the other in order to do this. Just - in what hacky way ever - calling a video driver's Enter/LeaveVT will have very unpleasant and unexpected results. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Retrieve XScreensaver queries only for a single widget
Hello, i'm fairly new to this list, hopefully i'm not offtopic. Please tell me otherwise :) I try to use the XScreensaver extension for my app. I'd like to hide my application after a while when the user does not interact with my app-widget. Means: If the user does not move the mouse over my widget for a specified time, the widget should hide. My first idea was to query X screensaver events, which in its basics works. But i've only been able to query events for the entire X11 display. Can someone tell me please: Is it possible to retrieve information from the XScreensaver extension for only a specified widget and not for the entire display? I'd like to ask the screensaver how long did my application not receive any mouse events? or how long has the user been idle regarding my app-window? I hope i did make myself clear enough. Can someone give me advice? I searched google a lot without finding any good documentation about the XScreensaver extension and how to use it. Thank you very much, Thomas -- Just because the message may never be received does not mean it is not worth sending. pgp0.pgp Description: signature
Re: Retrieve XScreensaver queries only for a single widget
On Mon, 3 Nov 2003 23:03:34 +0100 Thomas Reitelbach [EMAIL PROTECTED] (Bbabbled: (B (B Hello, (B (B i'm fairly new to this list, hopefully i'm not offtopic. Please tell me (B otherwise :) (B (B I try to use the XScreensaver extension for my app. (B I'd like to hide my application after a while when the user does not interact (B with my app-widget. Means: If the user does not move the mouse over my widget (B for a specified time, the widget should hide. (B My first idea was to query X screensaver events, which in its basics works. (B But i've only been able to query events for the entire X11 display. (B (B Can someone tell me please: Is it possible to retrieve information from the (B XScreensaver extension for only a specified widget and not for the entire (B display? I'd like to ask the screensaver "how long did my application not (B receive any mouse events?" or "how long has the user been idle regarding my (B app-window?" (B (B I hope i did make myself clear enough. (B (B Can someone give me advice? I searched google a lot without finding any good (B documentation about the XScreensaver extension and how to use it. (B (Bno. the screensaver extension is designed to do the whole display - moue AND (Bkeyboard. just "do it yourself". you get events on your widget/window. whenever (Byou get an event delete the old timer you set up (if you have one) then create a (Bnew timer to time out in N seconds (or minutes). when the timer runs, hide the (Bwidget. pretty simple. you'll have to figure out how to hook to motion/button (Betc. events through your widget set., but they are the basics of what drives (Byour widget set anyway. (B (B Thank you very much, (B Thomas (B (B -- (B Just because the message may never be received does not mean it is (B not worth sending. (B (B (B (B-- (B--- Codito, ergo sum - "I code, therefore I am" (BThe Rasterman (Carsten Haitzler)[EMAIL PROTECTED] $B7'<*(B - $Bhttp://XFree86.Org/mailman/listinfo/devel
Re: Retrieve XScreensaver queries only for a single widget
On Monday 03 November 2003 23:09, Carsten Haitzler wrote: (B On Mon, 3 Nov 2003 23:03:34 +0100 Thomas Reitelbach [EMAIL PROTECTED] (B babbled: (B (B I try to use the XScreensaver extension for my app. (B I'd like to hide my application after a while when the user does not (B interact (B with my app-widget. Means: If the user does not move the mouse (B over my widget for a specified time, the widget should hide. (B My first idea was to query X screensaver events, which in its basics (B works. (B But i've only been able to query events for the entire X11 (B display. (B Can someone tell me please: Is it possible to retrieve information from (B the (B XScreensaver extension for only a specified widget and not for the (B entire display? I'd like to ask the screensaver "how long did my (B application not receive any mouse events?" or "how long has the user been (B idle regarding my app-window?" (B (B I hope i did make myself clear enough. (B (B Can someone give me advice? I searched google a lot without finding any (B good (B documentation about the XScreensaver extension and how to use it. (B (B (B no. the screensaver extension is designed to do the whole display - moue (B AND (B keyboard. just "do it yourself". you get events on your widget/window. (B whenever you get an event delete the old timer you set up (if you have one) (B then create a new timer to time out in N seconds (or minutes). when the (B timer runs, hide the widget. pretty simple. you'll have to figure out how (B to hook to motion/button etc. events through your widget set., but they are (B the basics of what drives your widget set anyway. (B (BThank you, this is exactly the information i needed to _not_ search any longer (Bfor a XScreensaver solution. (BI'll do it myself, just want to be sure to not reinvent the wheel :-) (B (BThank you, (BThomas (B (B-- (BJust because the message may never be received does not mean it is (Bnot worth sending. pgp0.pgp Description: signature
Re: Nvidia driver relation to XFree
On Mon, 3 Nov 2003, Tim Roberts wrote: Just noticed a couple of (obviously accidental) inaccuracies which I thought I'd try to clear up a bit as the original poster might be confused a bit from some slightly conflictual statements that are IMHO obvious typo/thinkos. The video driver is part of XFree86. I don't think that this is neccessarily true, or is it? Yes, it is. I don'tknow how it is for other cards but in case of NVidia you have this kernel module nvidia.o which you need to load and in the Device section I specify as driver nvidia. nvidia.o is not a kernel module. It's not? ;o) It is just a dynamically loaded object file that gets loaded by the XFree86 dynamic loader and called entirely in user mode. That's nv_drv.o for the XFree86 supplied driver, and nvidia_drv.o for the Nvidia supplied proprietary one of course. It could have been done as an ordinary .so DLL, but the design objective was to have these work regardless of operating system. That's why there is a loader built-in to XFree86. A debateable benefit considering the amount of additional developmental hurdles the ELF loader brings with it, including extra unnecessary complexities trying to debug a modular X server, and requiring a special patched gdb, or to do a static build, which often times then doesn't show the problem anymore, etc. etc. And then there's the fact of how truely few non-OSS modules exist out there, and wether they actually do operate across different OS's of the same architecture. IMHO the ELF loader is only a real win for all it's costs if proprietary-only modules without source code truely work on all OS's. But that's debateable I'm sure, and kindof a side topic, so I digress. Of course it could be that this is just a name which coincides with the kernel module name. I assumed that it is the name of the module that is the driver, but I realize that this is not neccessarily so. Some drivers DO have kernel modules, to handle the DMA transfers that are necessary for adequate 3D operation. However, kernel drivers are loaded with insmod. modprobe actually. ;o) Do you mean that this driver also has some part within X itself? ALL XFree86 graphics drivers are part of XFree86. The interface they use is specified by and used by the XFree86 executable ONLY. Have you never looked at the XFree86 source code? You need to do so. Really. Much of this would be cleared up. Agreed. I think he is of the belief perhaps that an X driver module is perhaps like an SVGAlib API you can use in arbitrary programs perhaps including kernelspace, which of course isn't true. It owuld make sense I guess. But then where is this particular module? Is this also some closed source stuff from nVidia? At least I only had to download the kernel module and nothing else because Suse is not allowed to bundle it with their distribution. I suppose, that this would be true for a module within X as well. If the driver lives in /usr/X11R6/lib/modules/drivers and is named in XF86Config, it is NOT a kernel module. It is a dynamic library that is an integral part of XFree86. Or installed separately by a proprietary vendor's installation or third party project such as GATOS (for the case of ATI hardware, just as an example.) But the call of the EnterVT/LeaveVT has to end up in the kernel module somewhere, so I guess it should be possible to trace that and see what is called. NO, NO, NO! EnterVT/LeaveVT do NOT end up in a kernel module! The user-mode driver that is part of XFree86 does ALL of the register manipulation needed to change the video mode in and out of graphics. It's ALL done in the user-mode driver. For those drivers that DO have kernel components, the kernel sections are doing little more than DMA memory management, which cannot be done in user-mode. Register I/O and mode switching is STILL in user mode. That's of course all true... I think he just totally misunderstands XFree86 and it's driver architecture in general. Perhaps knowing that the majority of drivers don't even have a kernel module at all period is a clearer indicator that XFree86 and it's userland video driver modules do _everything_ WRT setting video modes, and configuring the hardware to blast pixels. ... Because the driver knows the card, it knows which of the addresses is the frame buffer and which has the memory-mapped registers. It maps that space into user-mode address space, and starts writing. And where can I find that code, which interacts with the driver? I think this EnterLeaveVT functions are only a small part of this. Is the most of that card dependent stuff in there as well? It doesn't INTERACT with the driver. It IS the driver. Every driver in the XFree86 source code (which you really need to read) includes EnterVT and LeaveVT entry points, that do whatever needs to be done to switch the board into and out of graphics mode. For many of the drivers, EnterVT and LeaveVT looks the same; they
Does anyone out there use mkxauth at all?
I'm curious as to wether or not anyone out there uses mkxauth at all out there still. My reason for asking, is that someone here at Red Hat (Jim Knoble) wrote it a long time ago, and we've included it in our distribution for a long time as well, however I'm not sure how many people out there use/require/want/care about it at all. I've not received any bug reports or problems about it forever now, which could be indicative that it doesn't have bugs, or could be indicative that nobody uses it anymore. If people do use it still, and there is usefulness in keeping it around, the original author Jim Knoble has previously authorized me to relicense the script from GPL to MIT in case the script would be considered something useful to include in upstream XFree86 along with xauth. So if anyone out there uses mkxauth at all still, please respond to me and let me know wether you still consider it useful or not, and if you'd miss it if it went away. If there is enough interest in it still, I'd be more than happy to submit the script under MIT license to XFree86.org if they're interested in having it somewhere in the repository. On the other hand, if it turns out nobody really uses it anymore, it might be best to just drop it from our distribution. I haven't used it in many years myself now, and kindof assumed most people use other mechanisms nowadays too, but didn't want to remove it and face the wrath. ;o) Feedback appreciated. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[Fonts] Ein einmaliges Angebot fur Fonts
Hallo Fonts ! Heute wollten wir Ihnen eine einmalige Gelegenheit bieten des beste Online-Livecam Angebot anonym und kostenlos zu testen. Seit mehreren Jahren betreiben wir eine kostenpflichtige Seite mit ueber 100 000 Videos, Bilder und Livecams. Ueber 10 000 Dauernutzer nutzen bereits unser Angebot und sind damit sehr zufrieden. Nun bekommen auch Sie eine einmalige Chance unser Angebot total kostenlos und anonym zu testen. Nur unter der unten angegebenen Adressen bekommen sie 3 Stunden kostenlosen Zugang zu unserem Server. Wir bieten sie das Angebot sich genauestens anzusehen und zu testen. Wir wundeschen ihnen viel Spass beim Geniessen. User Angebot: 2 Kontaktanzeigen 50 Livecams 5000 Bilder 2000 Videos 1000 Sexgeschichten und noch vieles Mehr! http://t3.to/cgi88837665.54656 Diese Nachricht wurde automatisch von unserem Nachrichtenserver geschickt! Wir uebernehmen keine Haftung fuer den Inhalt! ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts] Dunya Turuna Karavan Arkadaþý/Looking for a Caravan Mate For travel
Karavan ile Bir DdnyaTuru yapmay planlyorum. Hayalim olan bu Plan birlikte gerekletirmek zere: Bu turu hayal edebilecek kadar hayalgucu, Kalkp baarabilecek kadar cesareti, Zorluklarn gsleyebilecek kadar enerjisi, Bunu yapabilecek kadar zaman Can Dost kavramna inanc ve bu turun masraflarn paylaacak kadar paras olan, Araba kullanabilen,ehliyet sahibi Sigara meyen bir arkada aryorum. Eer seni aradm dnyorsan lutfen Mail ile temas kur ve telefon numaran yaz. Benimle ilgili ok ksa Bilgi: 1969 Doumlu/Erkek/stanbul Born 1969/Male/istanbul - Bu mail ile verdiim rahatszlktan dolay zr deilerim. lk ve son kez Gnderdim. i'm sorry because i disturbed you. I have sent it the first and the Last time. i'll never send another. it's meaning is i'm searching a caravan mate who want to travel all the world by a caravan. if you want to contact to me please send an e-mail to [EMAIL PROTECTED] with your phone number. ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [I18n] Using XIM - must give up compose keys
On Fri, Oct 31, 2003 at 11:06:39PM -0800, Hideki Hiura wrote: Do you specifically want to use XimLocal module and XimProto module at the same time? Or you want the local simple composition IM capability and the remote complex IM capability at the same time? To clarify what I am trying to do: I sometimes type English text, I sometimes type French text, and I sometimes type Japanese text. Typing French text requires the XimLocal functionality, and for typing Japanese text I use kinput. I use a UTF8 locale so having all this representable or output is not a problem, but for input, if XimProto is active, then XimLocal is not. I wanted to improve on this. If what you want is the latter, you may want to try IIIM Xlib module called xiiimp.so. By modifying the XIM entry of your /usr/X11R6/lib/X11/locale/current locale/XI18N_OBJS from [...] You can use localIM/remoteIM at the same time, and you can go back and forth among them. They are available from openi18n.org. Thank you for the suggestion. I tried to use this but I was hit by a learning curve. I installed Debian packages iiimf-htt-le-canna, iiimf-htt-xbe, and iiimf-htt-server. I modified XI18N_OBJS as you recommended. I never quite figured out how I was supposed to set $XMODIFIERS, but I finally got _SwitchOpenIM working. After that, Japanese input using canna worked, but only if the locale was ja_JP, it did not activate with ja_JP.UTF-8. And the compose key did not seem to work at all. I have not had time yet to diagnose further. -Phil ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] Using XIM - must give up compose keys
On Tue, 2003-11-04 at 03:06, Phillip Vandry wrote: Thank you for the suggestion. I tried to use this but I was hit by a learning curve. I installed Debian packages iiimf-htt-le-canna, iiimf-htt-xbe, and iiimf-htt-server. I modified XI18N_OBJS as you recommended. I never quite figured out how I was supposed to set $XMODIFIERS, but I finally got _SwitchOpenIM working. After that, Japanese input using canna worked, but only if the locale was ja_JP, it did not activate with ja_JP.UTF-8. And the compose key did not seem to work at all. If you're using the XI18N_OBJS method, then XMODIFIERS should be set to @im=local. Also note that the default Compose file for UTF-8 locales (/usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose) shipped with Debian is empty; you need to grab the Compose file suitable for use with xiiimp at the OpenI18N site. Regards Roger -- Roger So Community Representative Sun Wah Linux LimitedChinese Platform Developer Tel: +852 2250 0230 [EMAIL PROTECTED] Fax: +852 2259 9112 http://www.sw-linux.com/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[I18n] Dunya Turuna Karavan Arkadaþý/Looking for a Caravan Mate For travel
Karavan ile Bir DdnyaTuru yapmay planlyorum. Hayalim olan bu Plan birlikte gerekletirmek zere: Bu turu hayal edebilecek kadar hayalgucu, Kalkp baarabilecek kadar cesareti, Zorluklarn gsleyebilecek kadar enerjisi, Bunu yapabilecek kadar zaman Can Dost kavramna inanc ve bu turun masraflarn paylaacak kadar paras olan, Araba kullanabilen,ehliyet sahibi Sigara meyen bir arkada aryorum. Eer seni aradm dnyorsan lutfen Mail ile temas kur ve telefon numaran yaz. Benimle ilgili ok ksa Bilgi: 1969 Doumlu/Erkek/stanbul Born 1969/Male/istanbul - Bu mail ile verdiim rahatszlktan dolay zr deilerim. lk ve son kez Gnderdim. i'm sorry because i disturbed you. I have sent it the first and the Last time. i'll never send another. it's meaning is i'm searching a caravan mate who want to travel all the world by a caravan. if you want to contact to me please send an e-mail to [EMAIL PROTECTED] with your phone number. ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] Using XIM - must give up compose keys
From: iscas i18n group [EMAIL PROTECTED] Is That all need to do? Doesn't need something else like a modified version xlib, or some modification on environment variables setting? The mechanism itself is in xiiimp.so, which is a part of what we call IIIMXCF, which is a DL module for Xlib I18N enhancement that XFree86 Xlib has already incorporated. The sample Compose file I have posted to several MLs and also on openi18n.org website defines Japanese, Korean, Chinese, Thai, Indic as remoteIM, and English/European, Cyrillic, Greek, Arabic, Hebrew, Unicode Codepoint, Lookup from codechart as xiiimp.so's localIM. As far as you designate xiiimp.so for your IM module for Xlib instead of ximcp.so(X11R6 XIM protocol module)/ximp40.so(X11R5 XIM protocol module) you will get local/remote mixed multilingual Unicode IM. I'd like both ximlocal and ximcp/ximp40(R6 and R5 XIM protocol modules) and actually all XIM servers to be tapering out, because the combination of them does not really provide multilingual solution, its old design carries many limitations, and not extensible/flexible. I'm absolutely after you on this point, but I doubt if IIIMF is the right solution. To me, IIIMF seems too complex, too multi purposed, and too not X! To replace all XIM servers in all languages, to be competitive with Windows IMEs in all languages, meet wirh larger requirements from both serious apps and serious language engine, while maintaining backward compatibility, it is not going to be very simple. However, the principal of IIIMF architecture(Platform/Windowing system independnt central server + multiple platform/Windowing system binding) allow you to stay as simple as XIM Server model is, if you only need one platform. 1. IIIM Server instead of XIM Server for your IM server. 2. xiiimp.so instead of ximcp.so for you Xlib IM module. That's it. You will have XIM interface to access IM, and localIM/remoteIM switch-able Unicode IM. Optionally, if you want XIM protocol compatibility for remote X client which does not have xiiimp.so to display on your desktop, you can add 3. htt_xbe, which loads xiiimp.so and act as local XIM server. Best Regards, -- [EMAIL PROTECTED],OpenI18N.org,li18nux.org,unicode.org,sun.com} Chair, OpenI18N.org/The Free Standards Group http://www.OpenI18N.org Architect/Sr. Staff Engineer, Sun Microsystems, Inc, USA eFAX: 509-693-8356 ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] Using XIM - must give up compose keys
From: Phillip Vandry [EMAIL PROTECTED] I installed Debian packages iiimf-htt-le-canna, iiimf-htt-xbe, and iiimf-htt-server. I modified XI18N_OBJS as you recommended. Sounds good! I never quite figured out how I was supposed to set $XMODIFIERS, What's the value you set while you are testing? but I finally got _SwitchOpenIM working. After that, Japanese input using canna worked, but only if the locale was ja_JP, it did not activate with ja_JP.UTF-8. And the compose key did not seem to work at all. Did you modify all XI18N_OBJS for locales you use? Also did you install Compose file onto all locales you use? For example, If you use en_US.UTF-8 locale, both /usr/X11R6/lib/X11/locale/en_US.UTF-8/XI18N_OBJS /usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose should be replaced. If you use ja_JP.UTF-8 locale, both /usr/X11R6/lib/X11/locale/ja_JP.UTF-8/XI18N_OBJS /usr/X11R6/lib/X11/locale/ja_JP.UTF-8/Compose should be repalced. Did you see the IM status displaying [ English/European ]? In the sample Compose file on openi18n.org defines Multi_key as compose key. Multi_key is the key produces XK_Multi_Key keysym. Does your compose key produces XK_Multi_key keysym? For the keyboard which does not have compose key, the sample Compose file also defines CtrlT as an alternative, so you may want to give a try with CtrlT (control-shift-t pressed simultaneously). BTW, do you have any other XIM server running? If you have kinput2 running, you need to stop it to isolate the symptoms you encountered. Other thing to check: - Does IIIMF server (htt_server) running as a daemon launched from rc? - XMODIFIERS to be @im=local Best Regards, -- [EMAIL PROTECTED],OpenI18N.org,li18nux.org,unicode.org,sun.com} Chair, OpenI18N.org/The Free Standards Group http://www.OpenI18N.org Architect/Sr. Staff Engineer, Sun Microsystems, Inc, USA eFAX: 509-693-8356 ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[XFree86] i830 video ram problems
Hi, This is a request for help with an i830 video interface in a Gateway laptop (Solo 1450). Everything had been working happily in this system until I upgraded my BIOS. This laptop has some power management difficiencies I hoped would be addressed in the BIOS update. Anyway... the BIOS update has changed the laptop's video BIOS somehow so that it now thinks there's only 1MB of video ram installed when infact there's 8. I have been back and forth with Gateway on this asking them to provide me with the earlier BIOS so that I can revert the laptop. They *insist* it's impossible for the BIOS to be responsible for this (which is pure lunacy) and don't provide me with an earlier version. They are always very careful with their language: they never actually refuse my request for the earlier BIOS, instead they tell me this can't be the problem and that I must solve it some other way. Why they are not allowing me to pursue this remedy is beyond me but while I fight about it with them, I need to start investigating other options. I'm sick of working with 8 bit colour. So. This system has an i830M chipset in it and in the past has suffered from the 892 kB stolen memory problem that prevents either X or the BIOS (I don't understand which is responsible for what with this driver) from switching to the 1024x768 24-bit mode the LCD display is supposed to be capable of. Version 4.3.0 of XFree86 includes some sort of work-around that allows these chipsets to switch to higher modes despite the apparent lack of video ram. Until my BIOS upgrade this work-around seemed to be working. Now I'm back to the pre-4.3.0 behaviour of the video BIOS or X or whatever thinking it doesn't have enough video ram to switch to a high resolution, high colour-depth mode. Does anybody have an idea about this? Something to try? Also, if a graphics hardware guru could go on record for me saying this is a BIOS problem caused by the manufacturer's broken update that might help in my dealings with Gateway 'cause right now I can't, honestly, guarantee them their BIOS needs fixing: maybe it *was* broken, is now fixed, and the work-around in X is what's really broken... Anyway... just to make this as long-winded as possible, here's my XF86Config and my XFree86.0.log files. Thanks for the help. -Kipp Section Files RgbPath /usr/X11R6/lib/X11/rgb FontPathunix/:7100 EndSection Section Module Loaddbe Loadextmod Loadfbdevhw Loadglx Loadrecord Loadfreetype Loadtype1 Loaddri EndSection # See the keyboard(4x) man page for more information Section InputDevice Identifier Keyboard0 Driver keyboard Option XkbModel pc105 Option XkbLayout us Option XkbRules xfree86 EndSection # See the mouse(4x) man page for more information Section InputDevice Identifier Mouse0 Driver mouse Option Protocol IMPS/2 Option Device/dev/input/mice Option ZAxisMapping 4 5 EndSection # See the mouse(4x) man page for more information Section InputDevice Identifier Mouse1 Driver mouse Option Protocol MouseManPlusPS/2 # Option Protocol GlidePointPS/2 Option Device/dev/psaux Option Buttons 4 Option EmulateWheel yes EndSection Section Monitor Identifier Monitor0 VendorName Gateway ModelName Solo 1450 1024x768 LCD panel HorizSync 31.5 - 48.5 VertRefresh 40.0 - 70.0 Option dpms EndSection Section Device Identifier Videocard0 Driver i810 VendorName Gateway BoardName Intel 830M VideoRam8192 EndSection Section Screen Identifier Screen0 Device Videocard0 Monitor Monitor0 DefaultDepth8 SubSection Display Depth 8 Modes 1024x768 EndSubSection SubSection Display Depth 24 Modes 1024x768 EndSubSection EndSection Section ServerLayout Identifier Default Layout Screen 0 Screen0 0 0 InputDevice Mouse0CorePointer InputDevice Keyboard0 CoreKeyboard InputDevice Mouse1AlwaysCore EndSection Section DRI Group 0 Mode0666 EndSection XFree86 Version 4.3.0 (Fedora Core 1: 4.3.0-42) Release Date: 15 August 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.21-2.ELsmp i686 [ELF] Build Date: 24 October 2003 Build Host: porky.devel.redhat.com
[XFree86] (no subject)
___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: i830 video ram problems
On Mon, 3 Nov 2003, Kipp Cannon wrote: This is a request for help with an i830 video interface in a Gateway laptop (Solo 1450). Everything had been working happily in this system until I upgraded my BIOS. This laptop has some power management difficiencies I hoped would be addressed in the BIOS update. Anyway... the BIOS update has changed the laptop's video BIOS somehow so that it now thinks there's only 1MB of video ram installed when infact there's 8. That is a common problem with a lot of Dell laptops. I have been back and forth with Gateway on this asking them to provide me with the earlier BIOS so that I can revert the laptop. They *insist* it's impossible for the BIOS to be responsible for this (which is pure lunacy) and don't provide me with an earlier version. They are always very careful with their language: they never actually refuse my request for the earlier BIOS, instead they tell me this can't be the problem and that I must solve it some other way. The BIOS determines the default amount of system memory which is stolen for use by the integrated graphics hardware. The BIOS is supposed to allow the end user to change the default amount in the CMOS setup screen as per Intel documentation, however some manufacturers hard code this amount in the BIOS and do not allow the user to change it. Unfortunately their BIOS default is usually something rediculous like 1Mb. Please check your CMOS settings and ensure if there is an option to change the amount of stolen memory for video to something higher. If not, then you'll have to rely on the video driver to do it. Why they are not allowing me to pursue this remedy is beyond me but while I fight about it with them, I need to start investigating other options. I'm sick of working with 8 bit colour. It's not surprising that a vendor would only want to support their most recent BIOS image. It's up to the user to make a backup of their BIOS before flashing in order to allow them to go back if something doesn't work. In fact all documentation and software for flashing warns the user of this, at least in my experience. Why didn't you back up your existing BIOS first? So. This system has an i830M chipset in it and in the past has suffered from the 892 kB stolen memory problem that prevents either X or the BIOS (I don't understand which is responsible for what with this driver) from switching to the 1024x768 24-bit mode the LCD display is supposed to be capable of. Version 4.3.0 of XFree86 includes some sort of work-around that allows these chipsets to switch to higher modes despite the apparent lack of video ram. Until my BIOS upgrade this work-around seemed to be working. The work around is to use the VideoRAM option in the config file, which should override the BIOS default. To my knowledge however, that only works for certain Intel video hardware though, and not all hardware supported by the driver. Now I'm back to the pre-4.3.0 behaviour of the video BIOS or X or whatever thinking it doesn't have enough video ram to switch to a high resolution, high colour-depth mode. Does anybody have an idea about this? Something to try? Also, if a graphics hardware guru could go on record for me saying this is a BIOS problem caused by the manufacturer's broken update that might help in my dealings with Gateway 'cause right now I can't, honestly, guarantee them their BIOS needs fixing: maybe it *was* broken, is now fixed, and the work-around in X is what's really broken... Well, ultimately if you can't change the videoram size via the BIOS CMOS setup screen, the manufacturer is violating Intel's specifications, at least to my knowledge from when this problem initially was discovered a year and a half or so ago. Intel had a statement to that effect on developer.intel.com somewhere although I can't find it now. Section Device Identifier Videocard0 Driver i810 VendorName Gateway BoardName Intel 830M VideoRam8192 EndSection (II) Reloading /usr/X11R6/lib/modules/linux/libint10.a (II) I810(0): initializing int10 (WW) I810(0): Bad V_BIOS checksum (II) I810(0): Primary V_BIOS segment is: 0xc000 (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: Almador 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: Almador Graphics Controller (II) I810(0): VESA VBE OEM Product Rev: Hardware Version 0.0 (II) I810(0): Integrated Graphics Chipset: Intel(R) 830M (--) I810(0): Chipset: i830 (--) I810(0): Linear framebuffer at 0xE800 (--) I810(0): IO registers at addr 0xE008 (II) I810(0): detected 892 kB stolen memory. (II) I810(0): I830CheckAvailableMemory: 206844 kB available (**) I810(0): DRI is disabled because it runs only at depths 16 and 24. (II) I810(0): Will
[XFree86] *ERROR* Process 15549 using kernel context 0
I'm sure you've seen this one before, but I can't find an answer anywhere. I used to get DRI with my Radeon 7000, but I patched my 2.4.22 kernel with -ck2 and now I get the following message in dmesg: [drm] Initialized radeon 1.7.0 20020828 on minor 0 [drm:radeon_unlock] *ERROR* Process 15549 using kernel context 0 /var/log/XFree86.0.log doesn't show any errors, but I do get a warning (WW) RADEON(0): [agp] AGP not available and above that, (WW) RADEON(0): Cannot read colourmap from VGA. Will restore with default drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 6, (OK) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 6, (OK) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 6, (OK) drmGetBusid returned '' And a little after, it says that acceleration is enabled and direct rendering is disabled. Which, according to glxinfo, it is. I am fairly sure this has something to do with grsecurity, since if I don't compile it in I can get DRI, but nothing I can do (sysctl, chpax) changes anything if it is in. Obviously this skirts the line between a kernel issue and an X issue, but I thought I would ask here first. Ryan Reich ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Misconfigured CardBus bridge message
On Fri, 31 Oct 2003, [iso-8859-2] Martin MOKREJ© wrote: using 2.4.23-pre8 kernel and previous versions on ASUS L3800C I'm getting: (II) Module pcidata: vendor=The XFree86 Project compiled for 4.3.0.1, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.6 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x8000f940, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,1a30 card 1043,1626 rev 04 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,1a31 card , rev 04 class 06,04,00 hdr 01 (II) PCI: 00:1d:0: chip 8086,2482 card 1043,1628 rev 02 class 0c,03,00 hdr 80 (II) PCI: 00:1d:1: chip 8086,2484 card 1043,1628 rev 02 class 0c,03,00 hdr 00 (II) PCI: 00:1e:0: chip 8086,2448 card , rev 42 class 06,04,00 hdr 01 (II) PCI: 00:1f:0: chip 8086,248c card , rev 02 class 06,01,00 hdr 80 (II) PCI: 00:1f:1: chip 8086,248a card 1043,1628 rev 02 class 01,01,8a hdr 00 (II) PCI: 00:1f:5: chip 8086,2485 card 1043,1583 rev 02 class 04,01,00 hdr 00 (II) PCI: 00:1f:6: chip 8086,2486 card 1043,1496 rev 02 class 07,03,00 hdr 00 (II) PCI: 01:00:0: chip 1002,4c57 card 1043,1622 rev 00 class 03,00,00 hdr 00 (II) PCI: 02:05:0: chip 10ec,8139 card 1043,1045 rev 10 class 02,00,00 hdr 00 (II) PCI: 02:07:0: chip 1180,0476 card , rev a8 class 06,07,00 hdr 82 (II) PCI: 02:07:1: chip 1180,0476 card , rev a8 class 06,07,00 hdr 82 (II) PCI: 02:07:2: chip 1180,0552 card 1043,1627 rev 00 class 0c,00,10 hdr 80 (II) PCI: End of PCI scan (WW) Misconfigured CardBus bridge 2:7:0 (2,2) (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,4), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) PCI-to-PCI bridge: (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 1 I/O range: [0] -1 0 0xd000 - 0xdfff (0x1000) IX[B] (II) Bus 1 non-prefetchable memory range: [0] -1 0 0xd700 - 0xd7ef (0xf0) MX[B] (II) Bus 1 prefetchable memory range: [0] -1 0 0xd7f0 - 0xdfff (0x810) MX[B] (II) PCI-to-PCI bridge: (II) Bus 2: bridge is at (0:30:0), (0,2,2), BCTRL: 0x0006 (VGA_EN is cleared) (II) Bus 2 I/O range: [0] -1 0 0xa000 - 0xa0ff (0x100) IX[B] [1] -1 0 0xa400 - 0xa4ff (0x100) IX[B] [2] -1 0 0xa800 - 0xa8ff (0x100) IX[B] [3] -1 0 0xac00 - 0xacff (0x100) IX[B] (II) Bus 2 non-prefetchable memory range: [0] -1 0 0xd600 - 0xd6ff (0x100) 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) (II) PCI-to-CardBus bridge: (II) Bus 4: bridge is at (2:7:1), (2,4,7), BCTRL: 0x0700 (VGA_EN is cleared) (--) PCI:*(1:0:0) ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500] rev 0, Mem @ 0xd800/27, 0xd700/16, I/O @ 0xd 800/8, BIOS @ 0xd7fe/17 Could anyone tell me what to do with that message? I have compile PCMCIA kernel drivers as modules and they are not loaded now at all, but I'm still getting that message in /var/log/XFree86.0.log. This is nothing to worry about. It is only a warning informing you that one of the CardBus adapters in your system is not being used for anything and that, for reasons known only to the system BIOS, it left that bridge in a mis-configured (unusable) state. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Linux PPC Radeon bugs in -14,-15
Dear Sirs,
Observations on XFree86 4.3.99-15 (Mac Powerbook G4). Radeon 9000 LCD.
(Chipset ATI Radeon Mobility 9000 (M9) Lf (AGP) found). Linux 2.4.22,
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 440M
agpgart: Detected Apple UniNorth 1.5 chipset
agp: configuring for size idx: 4
agpgart: AGP aperture is 16M @ 0x0
[drm] Initialized radeon 1.9.0 20020828 on minor 0.
1) Suspend/Resume worked with 4.3.99-1{2,3} at least; with -14 and -15
the
machine locks hard with a corrupt screen on Resume. The last entry in
XFree86.0.log is:
(II) PM Event received: System Suspend Request
With -13, I get:
(II) PM Event received: System Suspend Request
(II) PM Event received: Normal Resume System
(II) RADEON(0): [RESUME] Attempting to re-init Radeon hardware.
(II) RADEON(0): [agp] Mode 0x0001 [Card 0x1002/0x4c66]
(EE) RADEON(0): [agp] AGP not enabled
2) Fails to use AGP:
RADEON(0): [agp] AGP not available
(WW) RADEON(0): [agp] AGP failed to initialize -- falling back to PCI
mode.
(WW) RADEON(0): [agp] If this is an AGP card, you may want to make
sure the
agpgart kernel module is loaded before the radeon kernel module.
Please note I routinely test bi-monthly drops, so no reply is necessary
unless you want more information or you'd like me to test something.
-jonathan
___
XFree86 mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Nvidia dual head, TV-out
Hi! I have a Nvidia Gforce card with dual heads and TV-out. How can I have the video overlay always display on the TV in fullscreen, no matter what's on the desktop monitor? That's how it worked on the Windows operating system, and I would like to use it on Linux too, but without using the Nvidia closed source drivers. Is it possible? Or planned to? Thanks, Hakon Gunsen
[XFree86] Dual-head MGA not working.
Hi, all. I've got a Debian machine with a G450 in the AGP slot, and another in a PCI slot. (bus 0x0001 cardnum 0x00 function 0x00 and bus 0x0003 cardnum 0x00 function 0x00, respectively). When I try to plug them both into my XF86Config file, though, I get this: (WW) MGA: No matching Device section for instance (BusID PCI:3:0:0) found Since I have the following Device section, the warning strikes me as disingenuous: Section Device Identifier g450-1 Driver mga Screen 1 Option SWcursor Option NoDDC BusID PCI:3:0:0 EndSection [Full XF86Config /var/log/XFree86.0.log appended to this e-mail.] Any ideas where I might be going wrong? Thanks, Ken D'Ambrosio Sr. SysAdmin, Xanoptix, Inc. [XF86Config-4] # XF86Config-4 (XFree86 X server configuration file) generated by dexconf, the # Debian X Configuration tool, using values from the debconf database. # # Edit this file with caution, and see the XF86Config-4 manual page. # (Type man XF86Config-4 at the shell prompt.) # # This file is automatically updated on xserver-xfree86 package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xfree86 # package. # # If you have edited this file but would like it to be automatically updated # again, run the following commands as root: # # cp /etc/X11/XF86Config-4 /etc/X11/XF86Config-4.custom # md5sum /etc/X11/XF86Config-4 /var/lib/xfree86/XF86Config-4.md5sum # dpkg-reconfigure xserver-xfree86 Section Files FontPathunix/:7100# local font server # if the local font server has problems, we can fall back on these FontPath/usr/lib/X11/fonts/Type1 FontPath/usr/lib/X11/fonts/CID FontPath/usr/lib/X11/fonts/Speedo FontPath/usr/lib/X11/fonts/misc FontPath/usr/lib/X11/fonts/cyrillic FontPath/usr/lib/X11/fonts/100dpi FontPath/usr/lib/X11/fonts/75dpi EndSection Section Module LoadGLcore Loadbitmap Loaddbe Loadddc Loaddri Loadextmod Loadfreetype Loadglx Loadint10 Loadrecord Loadspeedo Loadtype1 Loadvbe EndSection Section InputDevice Identifier Generic Keyboard Driver keyboard Option CoreKeyboard Option XkbRules xfree86 Option XkbModel pc104 Option XkbLayout us EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device/dev/psaux Option Protocol ImPS/2 Option ZAxisMapping 4 5 EndSection Section InputDevice Identifier Generic Mouse Driver mouse Option SendCoreEventstrue Option Device/dev/input/mice Option Protocol ImPS/2 Option ZAxisMapping 4 5 EndSection Section Device Identifier g450-0 Driver mga Screen 0 Option SWcursor Option NoDDC BusID PCI:1:0:0 EndSection Section Device Identifier g450-1 Driver mga Screen 1 Option SWcursor Option NoDDC BusID PCI:3:0:0 EndSection Section Monitor Identifier Monitor 0 # HorizSync 30-75 HorizSync 60 VertRefresh 50-85 Option DPMS EndSection Section Monitor Identifier Monitor 1 # HorizSync 30-75 HorizSync 60 VertRefresh 50-85 Option DPMS EndSection Section Screen Identifier Screen1 Device g450-1 Monitor Monitor 1 DefaultDepth24 SubSection Display Depth 1 Modes 1600x1200 1024x768 EndSubSection SubSection Display Depth 4 Modes 1600x1200 1024x768 EndSubSection SubSection Display Depth 8 Modes 1600x1200 1024x768 EndSubSection SubSection Display Depth 15 Modes 1600x1200 1024x768 EndSubSection SubSection Display Depth 16 Modes 1600x1200 1024x768 EndSubSection SubSection Display Depth 24 Modes 1600x1200 1024x768 EndSubSection EndSection
[XFree86] Dual Head detection
Hi! I've got a notebook with second head capability. I managed to have my second head working OK, but I have two layouts in my XF86Config-4, one describing a single head setup, and one the two-head setup. I was wondering if the X server had a way to detect that a second monitor is plugged in or not, and choose a layout based on that. What I'd like is : - not reboot the notebook - just restart the X-server (logging out is OK). GFX: radeom M6 LY kernel: 2.4.22-ac2 XFree86: 4.3.99.11 At boot time, the fradeonfb detects the presence/abscence of a second monitor, but will not update this at runtime. Is there a way to do this? Regards, Yann. -- .-..--.. | Yann E. MORIN | Real-Time Embedded | /\ ASCII RIBBON | Erics' conspiracy: | | +0/33 662376056 | Software Designer | \ / CAMPAIGN | ^| | --== °_° ==-- °---.: X AGAINST | /e\ There is no | | web: ymorin.free.fr | [EMAIL PROTECTED] 2377 | / \ HTML MAIL|conspiracy. | °-°°--°° \__ np: [Stopped] __/ ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] i830 video ram problems
Quoth Kipp Cannon: This is a request for help with an i830 video interface in a Gateway laptop (Solo 1450). Everything had been working happily in this system until I upgraded my BIOS. This laptop has some power management difficiencies I hoped would be addressed in the BIOS update. Anyway... the BIOS update has changed the laptop's video BIOS somehow so that it now thinks there's only 1MB of video ram installed when infact there's yep, this is a common problem with systems using intel's integrated graphics - most commonly laptops. My dell laptop has this exact same problem. It IS a BIOS problem. The bios is only pre-allocating 1MB of system memory at bootup, instead of 8 (as you want). (II) I810(0): detected 892 kB stolen memory. (II) I810(0): I830CheckAvailableMemory: 206844 kB available (**) I810(0): DRI is disabled because it runs only at depths 16 and 24. (II) I810(0): Will attempt to tell the BIOS that there is 8128 kB VideoRAM (WW) I810(0): Extended BIOS function 0x5f11 not supported. This tells you that it's a BIOS problem. The i810/i830 driver is attempting to tell the BIOS is got more memory. This is required since the driver uses the BIOS to programme the video modes. There is a patch here: http://www.chzsoft.com.ar/855patch.html but unfortunately, it's Dell-specific. You may be able to modify it to your needs. This patch has been included in the XFree86 source, but I don't know whether it's been generalised to all hardware (or is still dell specific). There more info here: http://www.xfree86.org/~dawes/845driver.html It doesn't solve your problem immediately, but it's a known problem with this hardware. Probably your best bet is really to get the old BIOS from gateway - maybe dig on their ftp site? sometimes they leave old versions lying about cheers chris -- - | | | TELESCOPE, n.| | A device having a relation to the eye similar to that of the | | telephone to the ear, enabling distant objects to plague us with a | | multitude of needless details. Luckily it is unprovided with a bell | | summoning us to the sacrifice. | | -- Ambrose Bierce, The Devil's Dictionary | | | - ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] BadAccess errors using XShmPutImage
i'm attempting to put together a simple test that creates a window, allocates a buffer in memory and using an XImage and XShmPutImage () displays it on my screen. i have a tiny piece of code that (as far as i know) does all the right things - it creates the window but when i try to display the contents of my buffer via an XImage i get a message like this: X Error of failed request: BadAccess (attempt to access private resource denied) Major opcode of failed request: 144 (MIT-SHM) Minor opcode of failed request: 3 (X_ShmPutImage) i've seen this type of problem described in the newsgroups but there don't seem to be any answers posted. i check the return from all my previous calls and they're fine. i'm using XFree86 version 4.3.0 (27 feb 2003), X Protocol version 11, rev 0, rel 6.6 and my OS is NetBSD/i386 1.6 [elf]. can anyone shed any light on this please? thanks. cp ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] BadAccess errors using XShmPutImage
i'm attempting to put together a simple test that creates a window, allocates a buffer in memory and using an XImage and XShmPutImage () displays it on my screen. i have a tiny piece of code that (as far as i know) does all the right things - it creates the window but when i try to display the contents of my buffer via an XImage i get a message like this: X Error of failed request: BadAccess (attempt to access private resource denied) Major opcode of failed request: 144 (MIT-SHM) Minor opcode of failed request: 3 (X_ShmPutImage) i've seen this type of problem described in the newsgroups but there don't seem to be any answers posted. i check the return from all my previous calls and they're fine. i'm using XFree86 version 4.3.0 (27 feb 2003), X Protocol version 11, rev 0, rel 6.6 and my OS is NetBSD/i386 1.6 [elf]. can anyone shed any light on this please? thanks. cp ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Nvidia dual head, TV-out
On Mon, 3 Nov 2003, Hakon Gunsen wrote: Hi! I have a Nvidia Gforce card with dual heads and TV-out. How can I have the video overlay always display on the TV in fullscreen, no matter what's on the desktop monitor? That's how it worked on the Windows operating system, and I would like to use it on Linux too, but without using the Nvidia closed source drivers. Is it possible? Having one head a TV with the video overlay and another head being a normal monitor without the video overlay is only possible in the separate X screens mode using NVIDIA's binary drivers. The open source driver that comes with XFree86 doesn't support TV-out or dual head operation. Mark. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] BadAccess errors using XShmPutImage
1) Does your X-server have SHM support? MIT-SHM should show up in the list of extensions reported by xdpyinfo. 2) Does your operating system have SHM support? This sort of thing is often disabled for security reasons. 3) Programming errors on your part? BadAccess is generated if: a) the server doesn't know about the segment (you called XShmAttach on it didn't you?). b) The size is bad, that is, the segment is too small to contain the source you specified (or the XImage is improperly initialized). Mark. On Mon, 3 Nov 2003, Callum Prentice wrote: i'm attempting to put together a simple test that creates a window, allocates a buffer in memory and using an XImage and XShmPutImage () displays it on my screen. i have a tiny piece of code that (as far as i know) does all the right things - it creates the window but when i try to display the contents of my buffer via an XImage i get a message like this: X Error of failed request: BadAccess (attempt to access private resource denied) Major opcode of failed request: 144 (MIT-SHM) Minor opcode of failed request: 3 (X_ShmPutImage) i've seen this type of problem described in the newsgroups but there don't seem to be any answers posted. i check the return from all my previous calls and they're fine. i'm using XFree86 version 4.3.0 (27 feb 2003), X Protocol version 11, rev 0, rel 6.6 and my OS is NetBSD/i386 1.6 [elf]. can anyone shed any light on this please? thanks. cp ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86 ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] BadAccess errors using XShmPutImage
1) Does your X-server have SHM support? MIT-SHM should show up in the list of extensions reported by xdpyinfo. Yep - that extension is listed when i run xdpyinfo. 2) Does your operating system have SHM support? This sort of thing is often disabled for security reasons. i'm not sure how to test this - i'm very much a x/unix novice - but after adding printf's to another library i've been looking at (SDL), it seems that it is - SDL is certainly calling XShmPutImage () successfully. 3) Programming errors on your part? BadAccess is generated if: Very likely. a) the server doesn't know about the segment (you called XShmAttach on it didn't you?). Yep - I do that. b) The size is bad, that is, the segment is too small to contain the source you specified (or the XImage is improperly initialized). I suspect that it is some kind of unitialized structure problem. I chopped the return value tests and the error handler out of my code for clarity and tacked it on the end of this message - might be something obvious. Thanks. cp snip shmInfo.shmid = shmget ( IPC_PRIVATE, windowWidth * windowDepthBytes * windowHeight, IPC_CREAT | 0777 ); shmInfo.shmaddr = (char *)shmat ( shmInfo.shmid, 0, 0); shminfo.readOnly = False; XShmAttach ( display, shmInfo ); XSync ( display, True ); shmctl ( shmInfo.shmid, IPC_RMID, NULL ); pixels = shmInfo.shmaddr; ximage = XShmCreateImage ( display, DefaultVisual ( display, screen ), windowDepth, ZPixmap, shmInfo.shmaddr, shmInfo, windowWidth, windowHeight ); XShmPutImage ( display, window, DefaultGC ( display, screen ), ximage, 0, 0, 0, 0, windowWidth, windowHeight, False ); -- i'm attempting to put together a simple test that creates a window, allocates a buffer in memory and using an XImage and XShmPutImage () displays it on my screen. i have a tiny piece of code that (as far as i know) does all the right things - it creates the window but when i try to display the contents of my buffer via an XImage i get a message like this: X Error of failed request: BadAccess (attempt to access private resource denied) Major opcode of failed request: 144 (MIT-SHM) Minor opcode of failed request: 3 (X_ShmPutImage) i've seen this type of problem described in the newsgroups but there don't seem to be any answers posted. i check the return from all my previous calls and they're fine. i'm using XFree86 version 4.3.0 (27 feb 2003), X Protocol version 11, rev 0, rel 6.6 and my OS is NetBSD/i386 1.6 [elf]. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] BadAccess errors using XShmPutImage
It's likely that you're not handling the padding correctly. Is (ximage-bytes_per_line == windowWidth * windowDepthBytes) ? In general, I like to create the XImage first and then allocate the data later. That saves you from having to do the work of finding out what the padding is supposed to be. That is, pass NULL for the data field in XShmCreateImage. Then shmget with (ximage-height * ximage-bytes_per_line), then fill in ximage-data with the value returned by shmat. Eg: ximage = XShmCreateImage(..., shminfo); shminfo.shmid = shmget (.., ximage-height * ximage-bytes_per_line, ...); shminfo.shmaddr = ximage-data = shmat(shminfo.shmid, 0, 0); shminfo.readOnly = False; XShmAttach (display, shminfo); So the pitch you should use is ximage-bytes_per_line. You can get that independently by looking up pixmap formats, but it's easier to just have XShmCreateImage fill it in for you. Mark. On Mon, 3 Nov 2003, Callum Prentice wrote: 1) Does your X-server have SHM support? MIT-SHM should show up in the list of extensions reported by xdpyinfo. Yep - that extension is listed when i run xdpyinfo. 2) Does your operating system have SHM support? This sort of thing is often disabled for security reasons. i'm not sure how to test this - i'm very much a x/unix novice - but after adding printf's to another library i've been looking at (SDL), it seems that it is - SDL is certainly calling XShmPutImage () successfully. 3) Programming errors on your part? BadAccess is generated if: Very likely. a) the server doesn't know about the segment (you called XShmAttach on it didn't you?). Yep - I do that. b) The size is bad, that is, the segment is too small to contain the source you specified (or the XImage is improperly initialized). I suspect that it is some kind of unitialized structure problem. I chopped the return value tests and the error handler out of my code for clarity and tacked it on the end of this message - might be something obvious. Thanks. cp snip shmInfo.shmid = shmget ( IPC_PRIVATE, windowWidth * windowDepthBytes * windowHeight, IPC_CREAT | 0777 ); shmInfo.shmaddr = (char *)shmat ( shmInfo.shmid, 0, 0); shminfo.readOnly = False; XShmAttach ( display, shmInfo ); XSync ( display, True ); shmctl ( shmInfo.shmid, IPC_RMID, NULL ); pixels = shmInfo.shmaddr; ximage = XShmCreateImage ( display, DefaultVisual ( display, screen ), windowDepth, ZPixmap, shmInfo.shmaddr, shmInfo, windowWidth, windowHeight ); XShmPutImage ( display, window, DefaultGC ( display, screen ), ximage, 0, 0, 0, 0, windowWidth, windowHeight, False ); -- i'm attempting to put together a simple test that creates a window, allocates a buffer in memory and using an XImage and XShmPutImage () displays it on my screen. i have a tiny piece of code that (as far as i know) does all the right things - it creates the window but when i try to display the contents of my buffer via an XImage i get a message like this: X Error of failed request: BadAccess (attempt to access private resource denied) Major opcode of failed request: 144 (MIT-SHM) Minor opcode of failed request: 3 (X_ShmPutImage) i've seen this type of problem described in the newsgroups but there don't seem to be any answers posted. i check the return from all my previous calls and they're fine. i'm using XFree86 version 4.3.0 (27 feb 2003), X Protocol version 11, rev 0, rel 6.6 and my OS is NetBSD/i386 1.6 [elf]. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Dunya Turuna Karavan Arkadaþý/Looking for a Caravan Mate For travel
Karavan ile Bir DdnyaTuru yapmay planlyorum. Hayalim olan bu Plan birlikte gerekletirmek zere: Bu turu hayal edebilecek kadar hayalgucu, Kalkp baarabilecek kadar cesareti, Zorluklarn gsleyebilecek kadar enerjisi, Bunu yapabilecek kadar zaman Can Dost kavramna inanc ve bu turun masraflarn paylaacak kadar paras olan, Araba kullanabilen,ehliyet sahibi Sigara meyen bir arkada aryorum. Eer seni aradm dnyorsan lutfen Mail ile temas kur ve telefon numaran yaz. Benimle ilgili ok ksa Bilgi: 1969 Doumlu/Erkek/stanbul Born 1969/Male/istanbul - Bu mail ile verdiim rahatszlktan dolay zr deilerim. lk ve son kez Gnderdim. i'm sorry because i disturbed you. I have sent it the first and the Last time. i'll never send another. it's meaning is i'm searching a caravan mate who want to travel all the world by a caravan. if you want to contact to me please send an e-mail to [EMAIL PROTECTED] with your phone number. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Dunya Turuna Karavan Arkadaþý/Looking for a Caravan Mate For travel
Karavan ile Bir DdnyaTuru yapmay planlyorum. Hayalim olan bu Plan birlikte gerekletirmek zere: Bu turu hayal edebilecek kadar hayalgucu, Kalkp baarabilecek kadar cesareti, Zorluklarn gsleyebilecek kadar enerjisi, Bunu yapabilecek kadar zaman Can Dost kavramna inanc ve bu turun masraflarn paylaacak kadar paras olan, Araba kullanabilen,ehliyet sahibi Sigara meyen bir arkada aryorum. Eer seni aradm dnyorsan lutfen Mail ile temas kur ve telefon numaran yaz. Benimle ilgili ok ksa Bilgi: 1969 Doumlu/Erkek/stanbul Born 1969/Male/istanbul - Bu mail ile verdiim rahatszlktan dolay zr deilerim. lk ve son kez Gnderdim. i'm sorry because i disturbed you. I have sent it the first and the Last time. i'll never send another. it's meaning is i'm searching a caravan mate who want to travel all the world by a caravan. if you want to contact to me please send an e-mail to [EMAIL PROTECTED] with your phone number. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Dunya Turuna Karavan Arkadaþý/Looking for a Caravan Mate For travel
Karavan ile Bir DdnyaTuru yapmay planlyorum. Hayalim olan bu Plan birlikte gerekletirmek zere: Bu turu hayal edebilecek kadar hayalgucu, Kalkp baarabilecek kadar cesareti, Zorluklarn gsleyebilecek kadar enerjisi, Bunu yapabilecek kadar zaman Can Dost kavramna inanc ve bu turun masraflarn paylaacak kadar paras olan, Araba kullanabilen,ehliyet sahibi Sigara meyen bir arkada aryorum. Eer seni aradm dnyorsan lutfen Mail ile temas kur ve telefon numaran yaz. Benimle ilgili ok ksa Bilgi: 1969 Doumlu/Erkek/stanbul Born 1969/Male/istanbul - Bu mail ile verdiim rahatszlktan dolay zr deilerim. lk ve son kez Gnderdim. i'm sorry because i disturbed you. I have sent it the first and the Last time. i'll never send another. it's meaning is i'm searching a caravan mate who want to travel all the world by a caravan. if you want to contact to me please send an e-mail to [EMAIL PROTECTED] with your phone number. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Dunya Turuna Karavan Arkadaþý/Looking for a Caravan Mate For travel
Karavan ile Bir DdnyaTuru yapmay planlyorum. Hayalim olan bu Plan birlikte gerekletirmek zere: Bu turu hayal edebilecek kadar hayalgucu, Kalkp baarabilecek kadar cesareti, Zorluklarn gsleyebilecek kadar enerjisi, Bunu yapabilecek kadar zaman Can Dost kavramna inanc ve bu turun masraflarn paylaacak kadar paras olan, Araba kullanabilen,ehliyet sahibi Sigara meyen bir arkada aryorum. Eer seni aradm dnyorsan lutfen Mail ile temas kur ve telefon numaran yaz. Benimle ilgili ok ksa Bilgi: 1969 Doumlu/Erkek/stanbul Born 1969/Male/istanbul - Bu mail ile verdiim rahatszlktan dolay zr deilerim. lk ve son kez Gnderdim. i'm sorry because i disturbed you. I have sent it the first and the Last time. i'll never send another. it's meaning is i'm searching a caravan mate who want to travel all the world by a caravan. if you want to contact to me please send an e-mail to [EMAIL PROTECTED] with your phone number. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
