More X servers on one virtual area
Hello, I would like to ask, if following problem has been solved by somebody: We have four single board computers with graphic accelerators. We have running Linux+X server on each of computer successfully. Each of computer is connected to one LCD panel. For now, we would like to use these four LCD screens like one big virtual area with one mouse cursor. I think Xinerama is right solution for more graphic cards connected to one computer, but we have separate computers. Could you please suggest any solution or way to solve this problem ? Thank you in advance, Jan Damborsk ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Servicios de hospedaje Web y Registro de Dominios, desde 3.95 dlls
*Hospedaje Web desde $3.95 dlls Paquetes de hospedaje web con las mejores características, con planes que se ajustan a tus necesidades. *Dominios desde $9.95 dlls Registra, renueva, transfiere, date de alta como revendedor de dominios, tenemos las herramientas que necesitas. *Hospedaje Revendedores desde $19.95 dlls Buscas hospedaje para múltiples dominios o quieres convertirte en revendedor de hospedaje Web, no busques mas. *Servidores Dedicados desde $125 dlls Alto trafico, sitios con ancho de banda intensa, o necesitas protección de datos, tenemos la solución. Para Saber mas vistita: http://www.mexcomp.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: More X servers on one virtual area
On Tue, 17 Feb 2004 19:04 pm, Jan Damborsky wrote: Each of computer is connected to one LCD panel. For now, we would like to use these four LCD screens like one big virtual area with one mouse cursor. X2X - http://freshmeat.net/projects/x2x/ Brad pgp0.pgp Description: signature
Re: More X servers on one virtual area
On Tue, 2004-02-17 at 09:04, Jan Damborsky wrote: We have four single board computers with graphic accelerators. We have running Linux+X server on each of computer successfully. Each of computer is connected to one LCD panel. For now, we would like to use these four LCD screens like one big virtual area with one mouse cursor. Check out DMX (http://dmx.sourceforge.net/). -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: radeon dri lockup
On Tue, 2004-02-17 at 02:14, Jonathan Isom wrote: Section Device Option Accel # [bool] Option AGPMode 2 Option EnableDepthMoves True# [bool] Have you tried without these two? Option AGPFastWrite False Option HWCursor True Identifier Card0 Driver radeon VendorName ATI BoardName Radeon RV100 QY [Radeon 7000/VE] BusID PCI:1:0:0 VideoRam65536 Is this correct? The VideoRam directive should only be used to override an incorrectly determined amount of video RAM, it's potentially harmful otherwise. EndSection -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: More X servers on one virtual area
Michel Dnzer wrote: On Tue, 2004-02-17 at 09:04, Jan Damborsky wrote: We have four single board computers with graphic accelerators. We have running Linux+X server on each of computer successfully. Each of computer is connected to one LCD panel. For now, we would like to use these four LCD screens like one big virtual area with one mouse cursor. Check out DMX (http://dmx.sourceforge.net/). It seems DMX is exactly what we need :). Thank you very much. Sincerelly, Jan Damborsky ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Question about nplanes and ColormapEntries in VisualRec
I'm making some changes to the server-side GLX in the DRI tree. For part of my changes I want to eliminate the need for libGLcore to have access to a VisualRec (programs/Xserver/include/scrnintstr.h, line 68). There are only two fields from that structure that are accessed by libGLcore, and I believe those values can be otherwise derrived, but I want to be sure. First, a comment in the structure says that nplanes is log2 (ColormapEntries). Does that mean that (1U v-nplanes) == v-ColormapEntries is always true? Second, for TrueColor and DirectColor visuals, is it safe to assume nplanes is the sum of the red, green, and blue bits? ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Fake Video Bios. How?
Hi all, I want use a VTBook card (www.villagetronic.com) with XFree86 4.3.0. This card is based on Trident XP2 graphics chip. Note that: - this graphics chip is currently unsupported by XFree86. I use the vesa driver; - graphics card is based on Cardbus (32bit PCMCIA); - card does not include video BIOS onboard. Bios must be loaded after hotplug event. - I have got the binary image of BIOS (VBE 2.0 compliant) I tried some XF86Config Options such as: Option BiosLocation address Set the location of the BIOS for the Int10 module. One may select a BIOS of another card for posting or the legacy V_BIOS range located at 0xc or an alternative address (BUS_ISA). This is only useful under very special circumstances and should be used with extreme care. Option BiosBase address but they are not the solution. I tried to map /dev/mem and put a copy of video BIOS in V_BIOS (0xC) before running X, but this way was not successful. How soft boot secondary cards if they have not a video BIOS? Do you know some utility to load bios in a way ready to be used by XFree86? Any idea? Thanks in advance, Guido ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Question about nplanes and ColormapEntries in VisualRec
Around 9 o'clock on Feb 17, Ian Romanick wrote: First, a comment in the structure says that nplanes is log2 (ColormapEntries). Does that mean that (1U v-nplanes) == v-ColormapEntries is always true? no. ColormapEntries on a Direct/True visual is 1 max(nred,ngreen,nblue). Second, for TrueColor and DirectColor visuals, is it safe to assume nplanes is the sum of the red, green, and blue bits? no. There may be extra bits which have no defined meaning in the core protocol which are used by extensions. -keith pgp0.pgp Description: PGP signature
Re: Question about nplanes and ColormapEntries in VisualRec
Keith Packard wrote: Around 9 o'clock on Feb 17, Ian Romanick wrote: First, a comment in the structure says that nplanes is log2 (ColormapEntries). Does that mean that (1U v-nplanes) == v-ColormapEntries is always true? no. ColormapEntries on a Direct/True visual is 1 max(nred,ngreen,nblue). Okay, then that comment is a little misleading for those cases, but I can live with it. Second, for TrueColor and DirectColor visuals, is it safe to assume nplanes is the sum of the red, green, and blue bits? no. There may be extra bits which have no defined meaning in the core protocol which are used by extensions. The GLX extension usually adds some bits for alpha for it's visuals (and those are the only visuals I care about in this case). However, even in the case where there's 32 bits total (including the alpha channel), nplanes is still only 24. So, let me phrase my original question a different way. Since the GLX extension sets nplanes in its added visuals, can it make whatever assumptions about nplanes it wants? :) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Modifications to linuxPci.c to optimize PCI scan
Pier Paolo Glave wrote: I'm trying to optimize an embedded system based on ARM9 CPU, which is running a cross-compiled version of XFree86 4.3.0 on linux 2.4.18. I noticed that XFree86, at start-up, makes a complete scan of 256 possible PCI buses, looking for devices, without checking (e.g. from /proc/bus/pci) how many buses are actually present on the system. I thought that in my system, where I have one bus only, this could lead to a high startup time, so I tried to make a patch (reported below) that detects the actual number of buses by parsing /proc/bus/pci/devices. The results were not amazing, because the saved time is really little. Right. The gain is very, very small, and it comes at the cost of an additional dependency on the presence and exact format of /proc/bus/pci/devices. /proc/bus was not introduced until the 2.2 kernels, so your change would prevent XFree86 from running on 2.0.x kernels. I don't know whether there are other issue with 2.0.x kernels or not, but since the cost of a full PCI bus search is so small, it seems counterproductive to make this change. -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Rendimento com Internet
Empresa procura Pessoas, Profissionais e Empresários, para Trabalho e Parceria com E-Business, usando a Internet. Detalhes no site ou na Apresentação Gratuita em São Paulo. Visite: http://www.hipernegocio.net Mauricio L. Costa NGTCorp - Dúvidas pelo email [EMAIL PROTECTED] Para ser removido de futuros correios, por favor, envie email para [EMAIL PROTECTED], com o assunto REMOVER. Obrigado. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 4.4.0 RC3
On Sun, Feb 15, 2004 at 10:45:11PM -0500, David Dawes wrote: The third release candidate for XFree86 4.4.0 (aka 4.3.99.903) has been tagged. Source and patches can be found at http://www.xfree86.org/develsnaps/. The download area at ftp://ftp.xfree86.org/pub/XFree86/snapshots/4.3.99.903/ will be populated over the next few days. The source is there now, and binaries will follow. Binaries for a range of popular platforms are now available. The latest documentation for this release can be found at http://www.xfree86.org/~dawes/pre-4.4/. Send any corrections, etc here. In particular, check the Release Notes, and send in details of new stuff that isn't mentioned there, and errors/omissions in the Credits section. If you have contributed to XFree86 4.4, make sure your name is listed! Also check the LICENSE document http://www.xfree86.org/~dawes/pre-4.4/LICENSE.html. There is a lot of FUD being circulated about the licensing, so check here for the facts. Also check out the FSF's Free Software definition and their list of licenses, as well as the OSI's Open Source Definition. There are links to these sites from our LICENSE document. In particular, follow up with the BSD licences (original and revised), the FreeType License (FTL), the SGI Free Software License (which applies to GLX and CID), and the Apache 1.1 licence. Don't rely on the FUD being circulated by people who can barely hide their prejudice. Go straight to the definitive sources on licensing issues, namely the FSF and the OSI, and come to your own conclusions. David ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: radeon dri lockup
On 2004-02-17 04:38:31 -0600 Michel Dänzer [EMAIL PROTECTED] wrote: On Tue, 2004-02-17 at 02:14, Jonathan Isom wrote: Section Device Option Accel # [bool] Option AGPMode 2 Option EnableDepthMoves True# [bool] Have you tried without these two? doesn't help Option AGPFastWrite False Option HWCursor True Identifier Card0 Driver radeon VendorName ATI BoardName Radeon RV100 QY [Radeon 7000/VE] BusID PCI:1:0:0 VideoRam65536 Is this correct? The VideoRam directive should only be used to override an incorrectly determined amount of video RAM, it's potentially harmful otherwise. EndSection ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 4.4.0 RC3
On Tue, 17 Feb 2004, David Dawes wrote: Also check the LICENSE document http://www.xfree86.org/~dawes/pre-4.4/LICENSE.html. There is a lot of FUD being circulated about the licensing, so check here for the facts. Also check out the FSF's Free Software definition and their list of licenses, as well as the OSI's Open Source Definition. There are links to these sites from our LICENSE document. In particular, follow up with the BSD licences (original and revised), the FreeType License (FTL), the SGI Free Software License (which applies to GLX and CID), and the Apache 1.1 licence. Don't rely on the FUD being circulated by people who can barely hide their prejudice. Go straight to the definitive sources on licensing issues, namely the FSF and the OSI, and come to your own conclusions. So I must totally agree with you David. People should indeed go to the definitive sources on open source licensing issues, the FSF and the OSI. Interestingly enough, neither the XFree86 license version 1.0, nor the new 1.1 license are listed as OSI approved open source licenses: http://www.opensource.org/licenses/index.php Going to the Free Software Foundations site to see their list of approved free software licenses, the XFree86 license version 1.0 and 1.1 are also noteably missing: http://www.fsf.org/licenses/license-list.html The FSF does have the following: The X11 license. This is a simple, permissive non-copyleft free software license, compatible with the GNU GPL. XFree86 uses the same license. This is sometimes called the MIT license, but that term is misleading since MIT has used many licenses for software. However that statement is inaccurate, as the parts of the XFree86 source code which are copyright by XFree86.org, are under either the XFree86 license version 1.0, or XFree86 license version 1.1. The simple conclusion, is that XFree86 is not free software, as defined by the Free Software Foundation nor open source software as defined by the Open Source Initiative, however there are a few inaccuracies present on both of these websites which need to be fixed, in order to not mislead people into beleiving XFree86 is MIT/X11 licensed. Of course, others should visit both websites and draw their own conclusions also, which will help to cut down on the FUD going around. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
