Re: How can we XGI share our Linux 2D driver with the open source community? Thanx
Yukun Chen wrote: Yes. We have done some optimization for h/w acceleration RENDER implementation but not including all aspects of our h/w. I have a practical example of a situation in which hardware accelerated RENDER is of great importance. I'm currently running the network of a newspaper that's in the process of moving back to the thin client model. We're using linux thin clients running on old hardware (~P133, 32MB RAM) backed by a dual Xeon server with 2GB of RAM. My experience so far has shown that any old hardware will work wonderfully as a thin client, so long as the graphics chipset is fast and well supported. The P133s are very sluggish with the built-in S3 graphics chips, but if upgraded to a PCI NVidia GEForce 4 MX they feel like one is sitting at the server console. The graphics card appears to be the primary factor in the performance of these systems. As such, I suspect that if your company had a quality, RENDER-accelerated driver included in XFree86, your hardware would be the _only_ choice for people wanting to deploy thin clients. Of course, that's not a huge market. On the other hand, anybody who wants good 2D performance is likely to prefer a card with good open-source drivers and H/W accelerated RENDER - even for a modern desktop. Yes, 3D would be nice - but currently the market for linux desktops seems mostly office based, and there it's snappy and responsive 2D - plus a driver already integrated into the OS - that's likely to make the difference. Of course, I only speak from my experience at a small-ish newspaper, I can't claim to see the whole picture. Craig Ringer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xdmcp and clients with multiple lan interfaces...
On Tue, Jan 13, 2004 at 04:37:23PM -0500, Rick Beldin wrote: >David Dawes wrote: > >> >> I'm assuming you mean that there is a 0.0.0.0 address in the >> connectionAddresses list passed from the X server to the xdm server? > > Yes, for example, on a Window XP laptop with lan, wireless, > and Nortel VPN software you get the following with the > internal lan connected and no wireless. OK, so this is on Windows. I didn't think I'd seen addresses like this get passed through on Linux or BSD platforms. >> The -from option was motivated by machines with multiple configured >> addresses. If an unconfigured interface address is getting added >> to the list of addresses, then I'd say that this is a bug in the >> X server. There may be similar bugs in other places that get a >> list of local addresses. >> > Seems like a trivial thing for the Xserver to filter out > an IP address of 0.0.0.0 - unless for some bizarre reason > you WANT this address. There isn't any reason to keep it. >> The -from option probably could be avoided in most cases, but there are >> still some configurations where it would remain useful. >> > Would one be the case where you have two active > lan Yep. >> While this should be corrected, other xdm-derived display managers >> probably have the same problem. For your specific problem, the >> best immediate solution might be to make sure that the X server >> doesn't include unconfigured interfaces in the list of addresses >> it passes to xdm. > > Other xdm-derived display managers do have the same problem. > dtlogin, from CDE, for example, tries to prevent xdm requests > to the loopback. A proto fix that I made appears to eliminate > attempts to connect to 0.0.0.0. I think it will be useful to > look into what it would take to only connect back the originator. > > Is this type of behavior something that you would want options > for? I still can't envision the situation where I would listen > for a request on one interface and then somehow decide to > respond on another. I don't see any need to have options, providing xdm only responds to the from address if it is included in the connection address list that the X server sends as part of the request packet. That way the X server could omit the from address from that list if there is some strange need for behaviour like that. Something like this on the xdm side should do it: if (fromaddr matches a connectionAddress) use fromaddr else use the current selection method David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Disbandment
On Tue, Jan 13, 2004 at 08:35:33PM -0500, William M. Quarles wrote: >Why are you disbanded? And does this mean that there will be no XFree86 >4.4 final? I'm not sure how you came to those conclusions from what it says at www.xfree86.org. And yes, there will be a 4.4.0 release (and a 4.5.0 release, etc). David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Disbandment
Why are you disbanded? And does this mean that there will be no XFree86 4.4 final? Thanks, William ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: How can we XGI share our Linux 2D driver with the open source community? Thanx
Until now we have no plan to release a non x86 binaries. But in future we might do sth. for this. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sven Luther Sent: Tuesday, January 13, 2004 6:47 PM To: [EMAIL PROTECTED] Subject: Re: How can we XGI share our Linux 2D driver with the open source community? Thanx On Tue, Jan 13, 2004 at 05:35:50PM +0800, Yukun Chen wrote: > Yes. We have done some optimization for h/w acceleration RENDER > implementation but not including all aspects of our h/w. > > Also I think we can improve the 2D performance with the help of the > buddy in open source community. But no 3D drivers :(( Do you plane to make closed source 3D drivers available and if so, do you intent to provide also non x86 binaries (asking as developer for a company which does produce powerpc micro-atx motherboards). Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: caps lock not working in XDarwin?
At 2:18 PM -1000 1/13/04, Jan Kleyna wrote: Hello, Apparently caps lock is not working under XDarwin (fault is in XDarwin.app). This is in the latest 4.4.0 RC 2 2nd candidate binary, on a Powermac G5 under OS X 10.3.1 and 10.3.2. Previous releases had the same problem. The problem is that it is necessary to hit capslock 3 times to turn off caps locking. I think the explanation is that the capslock key generates half the number of expected X events as on other platforms, so it has to be handled specially. Apologies if this is a known bug, or if this is the wrong list to send it to. Thanks for the feedback. This is the right list and it is timely to report these important bugs during our release candidate phase. This bug has been fixed in the current sources by disabling XKB by default in XDarwin. You should be able to use the XDarwin binary that you have by starting from the Terminal with "/Applications/XDarwin.app/Contents/MacOS/XDarwin -kb" or "startx -- -kb". --Torrey ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
caps lock not working in XDarwin?
Hello, Apparently caps lock is not working under XDarwin (fault is in XDarwin.app). This is in the latest 4.4.0 RC 2 2nd candidate binary, on a Powermac G5 under OS X 10.3.1 and 10.3.2. Previous releases had the same problem. The problem is that it is necessary to hit capslock 3 times to turn off caps locking. I think the explanation is that the capslock key generates half the number of expected X events as on other platforms, so it has to be handled specially. Apologies if this is a known bug, or if this is the wrong list to send it to. Regards, Jan ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xdmcp and clients with multiple lan interfaces...
Hi! Am Dienstag, 13.01.04 um 22:37 Uhr schrieb Rick Beldin: Seems like a trivial thing for the Xserver to filter out an IP address of 0.0.0.0 - unless for some bizarre reason you WANT this address. 0.0.0.0 is an old broadcast address. You probably do not want to use it as a node address. The X server passes xdm a list of addresses, and xdm chooses one based on its policy. The policy should probably be fixed to favour the address the request comes from. As it is now, there is no guarantee that the address it picks is even reachable (which I think was the real motivation for the -from option). Ok, so I am not missing something. I can't envision why you would want to go to other than the machine that sent out the request. The different addresses could use different protocols. X11 works over a variety of protocols, while XDMCP uses UDP (and with the recent changes UDP on IPv6) The X11 server could have additional addresses usable by xdm, so xdm could chooses one of them based on its policy. Other xdm-derived display managers do have the same problem. dtlogin, from CDE, for example, tries to prevent xdm requests to the loopback. A proto fix that I made appears to eliminate attempts to connect to 0.0.0.0. I think it will be useful to look into what it would take to only connect back the originator. 0.0.0.0 should not be included in the servers address list at all. This probably is a bug in the os dependent code to figure out the local addresses. Is this type of behavior something that you would want options for? I still can't envision the situation where I would listen for a request on one interface and then somehow decide to respond on another. I can imagine an X11 server sending xdmcp queries to a local xdm and adding unix:0 to the address list to let the xdm server use the fast UNIX type socket instead of an IP connection. However, the server currently is not smart enough to do this and server initiated connections to a local xdm are rarely used. 73, Mario -- Mario Klebsch [EMAIL PROTECTED] PGP-Key available at http://www.klebsch.de/public.key Fingerprint DSS: EE7C DBCC D9C8 5DC1 D4DB 1483 30CE 9FB2 A047 9CE0 Diffie-Hellman: D447 4ED6 8A10 2C65 C5E5 8B98 9464 53FF 9382 F518 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xdmcp and clients with multiple lan interfaces...
David Dawes wrote:
I'm assuming you mean that there is a 0.0.0.0 address in the
connectionAddresses list passed from the X server to the xdm server?
Yes, for example, on a Window XP laptop with lan, wireless,
and Nortel VPN software you get the following with the
internal lan connected and no wireless.
$ ipconfig /all
Windows IP Configuration
Host Name . . . . . . . . . . . . : SOMENAME
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
#thernet adapter Local Area Connection 2:
Connection-specific DNS Suffix . : some.domain.com
Description . . . . . . . . . . . : Intel(R) PRO/100 VM Network Connection
Physical Address. . . . . . . . . : 00-08-02-96-77-86
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : XX.XX.XX.XX
Subnet Mask . . . . . . . . . . . : XX.XX.XX.XX
Default Gateway . . . . . . . . . : XX.XX.XX.XX
DHCP Server . . . . . . . . . . . : XX.XX.XX.XX
DNS Servers . . . . . . . . . . . : XX.XX.XX.XX
XX.XX.XX.XX
Primary WINS Server . . . . . . . : XX.XX.XX.XX
Secondary WINS Server . . . . . . : XX.XX.XX.XX
Lease Obtained. . . . . . . . . . : Tuesday, January 13, 2004 12:24:01 P
Lease Expires . . . . . . . . . . : Monday, January 19, 2004 12:24:01 PM
Ethernet adapter {04D1B7C9-E37E-47A3-8385-BCD06ADC7AFD}:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Nortel IPSECSHM Adapter - Packet Sch
duler Miniport
Physical Address. . . . . . . . . : 44-45-53-54-42-00
Dhcp Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 0.0.0.0
Subnet Mask . . . . . . . . . . . : 0.0.0.0
Default Gateway . . . . . . . . . :
Ethernet adapter Wireless Network Connection:
Media State . . . . . . . . . . . : Media disconnected
Description . . . . . . . . . . . : Compaq WLAN MultiPort W200
Physical Address. . . . . . . . . : 00-0B-CD-8C-B2-A0
Note: I XX'd out all the company-specific IP addresses.
The -from option was motivated by machines with multiple configured
addresses. If an unconfigured interface address is getting added
to the list of addresses, then I'd say that this is a bug in the
X server. There may be similar bugs in other places that get a
list of local addresses.
Seems like a trivial thing for the Xserver to filter out
an IP address of 0.0.0.0 - unless for some bizarre reason
you WANT this address.
The -from option probably could be avoided in most cases, but there are
still some configurations where it would remain useful.
Would one be the case where you have two active
lan
The X server passes xdm a list of addresses, and xdm chooses one
based on its policy. The policy should probably be fixed to favour
the address the request comes from. As it is now, there is no
guarantee that the address it picks is even reachable (which I
think was the real motivation for the -from option).
Ok, so I am not missing something. I can't envision
why you would want to go to other than the machine that
sent out the request.
While this should be corrected, other xdm-derived display managers
probably have the same problem. For your specific problem, the
best immediate solution might be to make sure that the X server
doesn't include unconfigured interfaces in the list of addresses
it passes to xdm.
Other xdm-derived display managers do have the same problem.
dtlogin, from CDE, for example, tries to prevent xdm requests
to the loopback. A proto fix that I made appears to eliminate
attempts to connect to 0.0.0.0. I think it will be useful to
look into what it would take to only connect back the originator.
Is this type of behavior something that you would want options
for? I still can't envision the situation where I would listen
for a request on one interface and then somehow decide to
respond on another.
Thanks,
Rick
--
+--+
| Rick Beldin| Hewlett-Packard Company|
| email: rbeldinATatl.hp.com | Global Solutions Engineering |
|| 20 Perimeter Summit|
|| Atlanta, GA 30319 |
+--+
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: xdmcp and clients with multiple lan interfaces...
On Tue, Jan 13, 2004 at 02:58:34PM -0500, Rick Beldin wrote: >I was looking over some recent changes to xdm in policy.c: > > Revision 3.9 / (download) - annotate - [select for diffs], Thu Jan 1 17:12:34 >2004 UTC (12 days, 2 hours ago) by herrb >Branch: MAIN >CVS Tags: HEAD >Changes since 3.8: +23 -2 lines >Diff to previous 3.8 (unified) > >When handling a request paquet, select a supported connection type >if possible. If no supported connection is proposed, dont reject the >connection. Problem noticed by Mario Klebsch, fix by me. > >I've been working on similar problems where the client system (requestor) >has multiple lan interfaces that are visible to the OS, yet are not >configured. Such a situation can easily exist on a laptop with both >wired and wireless configurations and a VPN or a workstation with multiple >interfaces, one or more which are not configured. > >Such a situation will generate a request that appears to originate from >0.0.0.0. This situation is apparently what drove the -from option in >XFree86 Xserver. I'm assuming you mean that there is a 0.0.0.0 address in the connectionAddresses list passed from the X server to the xdm server? The -from option was motivated by machines with multiple configured addresses. If an unconfigured interface address is getting added to the list of addresses, then I'd say that this is a bug in the X server. There may be similar bugs in other places that get a list of local addresses. >While the -from is a viable workaround, I am curious as to real need for >this. Consider that in xdm's xdmcp.c request_respond(): The -from option probably could be avoided in most cases, but there are still some configurations where it would remain useful. > /* Check this Display against the Manager's policy */ > reason = Accept (from, fromlen, displayNumber); > if (reason) > goto decline; > > /* Check the Display's stream services against Manager's policy */ > i = SelectConnectionTypeIndex (&connectionTypes, > &connectionAddresses); > >The from variable contains information about the requestor. It has >the correct ip address of the machine that sent the request. Why >aren't we simply using that address to reply back to? Why go through >all the various connections? Would you want to get a request from one >IP address (from) and then respond to something else (in the connectionAddresses)? The X server passes xdm a list of addresses, and xdm chooses one based on its policy. The policy should probably be fixed to favour the address the request comes from. As it is now, there is no guarantee that the address it picks is even reachable (which I think was the real motivation for the -from option). While this should be corrected, other xdm-derived display managers probably have the same problem. For your specific problem, the best immediate solution might be to make sure that the X server doesn't include unconfigured interfaces in the list of addresses it passes to xdm. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
xdmcp and clients with multiple lan interfaces...
I was looking over some recent changes to xdm in policy.c: Revision 3.9 / (download) - annotate - [select for diffs], Thu Jan 1 17:12:34 2004 UTC (12 days, 2 hours ago) by herrb Branch: MAIN CVS Tags: HEAD Changes since 3.8: +23 -2 lines Diff to previous 3.8 (unified) When handling a request paquet, select a supported connection type if possible. If no supported connection is proposed, dont reject the connection. Problem noticed by Mario Klebsch, fix by me. I've been working on similar problems where the client system (requestor) has multiple lan interfaces that are visible to the OS, yet are not configured. Such a situation can easily exist on a laptop with both wired and wireless configurations and a VPN or a workstation with multiple interfaces, one or more which are not configured. Such a situation will generate a request that appears to originate from 0.0.0.0. This situation is apparently what drove the -from option in XFree86 Xserver. While the -from is a viable workaround, I am curious as to real need for this. Consider that in xdm's xdmcp.c request_respond(): /* Check this Display against the Manager's policy */ reason = Accept (from, fromlen, displayNumber); if (reason) goto decline; /* Check the Display's stream services against Manager's policy */ i = SelectConnectionTypeIndex (&connectionTypes, &connectionAddresses); The from variable contains information about the requestor. It has the correct ip address of the machine that sent the request. Why aren't we simply using that address to reply back to? Why go through all the various connections? Would you want to get a request from one IP address (from) and then respond to something else (in the connectionAddresses)? I must be missing something fundamental here. In looking at this problem it would appear that a simple fix for multiple interface clients would be to simply respond back to the originator. Thanks, Rick -- +--+ | Rick Beldin| Hewlett-Packard Company| | email: rbeldinATatl.hp.com | Global Solutions Engineering | || 20 Perimeter Summit| || Atlanta, GA 30319 | +--+ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: nv background light control patch.
OK. I've applied it.
Mark.
On Tue, 13 Jan 2004, Guido Guenther wrote:
> Hi Hugang,
> On Sun, Dec 28, 2003 at 02:00:13PM +0800, Hugang wrote:
> > I'm use PowerBook G4 with linux, Now I upgrade Xserver to 4.3.99.902.
> > Yes, from now NV driver can turn lcd light off, But here has a problem,
> > When light turn on again, The light level is change, So I writen this patch, Test
> > passed.
> You're right, the problem here is that I missed to restore a bit
> properly on unblank. Attached patch fixes this. Please apply since this
> fixes a bug in the release candidate.
>
> Index: programs/Xserver/hw/xfree86/drivers/nv/nv_driver.c
> ===
> RCS file: /cvs/xc/programs/Xserver/hw/xfree86/drivers/nv/nv_driver.c,v
> retrieving revision 1.122
> diff -u -p -r1.122 nv_driver.c
> --- programs/Xserver/hw/xfree86/drivers/nv/nv_driver.c10 Jan 2004 22:31:53
> - 1.122
> +++ programs/Xserver/hw/xfree86/drivers/nv/nv_driver.c13 Jan 2004 13:42:15
> -
> @@ -1512,13 +1514,15 @@ static void NVBacklightEnable(NVPtr pNv,
> (pNv->Chipset == 0x10DE0329))
> {
> /* NV17,18,34 Apple iMac, iBook, PowerBook */
> - CARD32 tmp;
> - tmp = pNv->PMC[0x10F0/4] & 0x7FFF;
> - pNv->PMC[0x10F0/4] = tmp;
> - tmp = pNv->PCRTC0[0x081C/4] & 0xFFFC;
> - if(on)
> - tmp |= 0x1;
> - pNv->PCRTC0[0x081C/4] = tmp;
> + CARD32 tmp_pmc, tmp_pcrt;
> + tmp_pmc = pNv->PMC[0x10F0/4] & 0x7FFF;
> + tmp_pcrt = pNv->PCRTC0[0x081C/4] & 0xFFFC;
> + if(on) {
> + tmp_pmc |= (1 << 31);
> + tmp_pcrt |= 0x1;
> + }
> + pNv->PMC[0x10F0/4] = tmp_pmc;
> + pNv->PCRTC0[0x081C/4] = tmp_pcrt;
> }
> #endif
> }
>
> Cheers,
> -- Guido
>
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: afbDoBitbltCopy location
On Wed, 14 Jan 2004, Tyler Retzlaff wrote: > Maybe I've been awake for too long, but I can't seem to find where > afbDoBitbltCopy() is implemented in xc/*. It is needed by > afbCopyArea, afbDoBitblt and afbCopyPlane.. > Where is it? grep is not helping me at this late hour. xc/programs/Xserver/afb/afbblt.c line 50. 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 developer and VP. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
afbDoBitbltCopy location
Maybe I've been awake for too long, but I can't seem to find where afbDoBitbltCopy() is implemented in xc/*. It is needed by afbCopyArea, afbDoBitblt and afbCopyPlane.. Where is it? grep is not helping me at this late hour. Thanks ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: nv background light control patch.
Hi Hugang,
On Sun, Dec 28, 2003 at 02:00:13PM +0800, Hugang wrote:
> I'm use PowerBook G4 with linux, Now I upgrade Xserver to 4.3.99.902.
> Yes, from now NV driver can turn lcd light off, But here has a problem,
> When light turn on again, The light level is change, So I writen this patch, Test
> passed.
You're right, the problem here is that I missed to restore a bit
properly on unblank. Attached patch fixes this. Please apply since this
fixes a bug in the release candidate.
Index: programs/Xserver/hw/xfree86/drivers/nv/nv_driver.c
===
RCS file: /cvs/xc/programs/Xserver/hw/xfree86/drivers/nv/nv_driver.c,v
retrieving revision 1.122
diff -u -p -r1.122 nv_driver.c
--- programs/Xserver/hw/xfree86/drivers/nv/nv_driver.c 10 Jan 2004 22:31:53 -
1.122
+++ programs/Xserver/hw/xfree86/drivers/nv/nv_driver.c 13 Jan 2004 13:42:15 -
@@ -1512,13 +1514,15 @@ static void NVBacklightEnable(NVPtr pNv,
(pNv->Chipset == 0x10DE0329))
{
/* NV17,18,34 Apple iMac, iBook, PowerBook */
- CARD32 tmp;
- tmp = pNv->PMC[0x10F0/4] & 0x7FFF;
- pNv->PMC[0x10F0/4] = tmp;
- tmp = pNv->PCRTC0[0x081C/4] & 0xFFFC;
- if(on)
- tmp |= 0x1;
- pNv->PCRTC0[0x081C/4] = tmp;
+ CARD32 tmp_pmc, tmp_pcrt;
+ tmp_pmc = pNv->PMC[0x10F0/4] & 0x7FFF;
+ tmp_pcrt = pNv->PCRTC0[0x081C/4] & 0xFFFC;
+ if(on) {
+ tmp_pmc |= (1 << 31);
+ tmp_pcrt |= 0x1;
+ }
+ pNv->PMC[0x10F0/4] = tmp_pmc;
+ pNv->PCRTC0[0x081C/4] = tmp_pcrt;
}
#endif
}
Cheers,
-- Guido
signature.asc
Description: Digital signature
Re: How can we XGI share our Linux 2D driver with the open source community? Thanx
On Tue, Jan 13, 2004 at 05:35:50PM +0800, Yukun Chen wrote: > Yes. We have done some optimization for h/w acceleration RENDER > implementation but not including all aspects of our h/w. > > Also I think we can improve the 2D performance with the help of the > buddy in open source community. But no 3D drivers :(( Do you plane to make closed source 3D drivers available and if so, do you intent to provide also non x86 binaries (asking as developer for a company which does produce powerpc micro-atx motherboards). Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
X problems on Marvel Discovery 2 based Pegasos 2 motherboard.
Hello, I have lately been working at porting the linux kernel to the Pegasos 2 motherboard (http://www.pegasosppc.com/tech_specs.php), which uses the Marvell Discovery 2 northbridge. Their site is currently down, but the web site should be : http://www.marvell.com/products/communication/discoveryII/MV64340.jsp Anyway, the discovery II posess two independent pci controllers, but also use the pci functions 0-5 or something such for not really pci-bridge conformant stuff. As a result, in the kernel i make the necessary things to either hide the pci controller, or just show enough information for it to be indentified. This works well with fbdev drivers, but X is less than happy about this. If i totally hide the device 0 pci configs (both read and write), X works well on radeons (altough using dri freeze after a few seconds on everything except the radeon 7500, but this is another issue, i think), but dies with the tdfx driver and voodoo 3 graphic cards. Also, in any case, i get the following message : (WW) INVALID IO ALLOCATION b: 0x1000 e: 0x10ff correcting^G Which i think may be linked to the problem, but i have not yet had time to go hunting for it in the sources. The tdfx driver further dies with : (EE) TDFX(0): No valid PIO address in PCI config space Any idea on where i should look ? Also, the motherboard contains a little magic thingy, which is supposed to transform one of the PCI buses into an AGP config space compatible bus, but which needs special treatment when reading or writing to the config space. I have the feeling that this is no problem, since on linux, XFree86 use the kernel facility to access config space. Anyway, i append the full log of the failed radeon case, where the marvell discovery bridge shows up. Any help on where to start to look would be welcome. BTW, this is with the debian 4.3.0-0pre1v5 X packages. Friendly, Sven Luther This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to [EMAIL PROTECTED] and patches submitted to [EMAIL PROTECTED] Before reporting bugs in pre-release versions, please check the latest version in the XFree86 CVS repository (http://www.XFree86.Org/cvs). XFree86 Version 4.3.0.1 (Debian 4.3.0-0pre1v5.1 20040107192252 [EMAIL PROTECTED]) Release Date: 15 August 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.23 ppc [ELF] Build Date: 07 January 2004 Before reporting problems, check http://www.XFree86.Org/ to make sure that you have the latest version. Module Loader present OS Kernel: Linux version 2.4.24 ([EMAIL PROTECTED]) (gcc version 3.3.3 20031229 (prerelease) (Debian)) #3 Tue Jan 13 10:22:42 CET 2004 Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/XFree86.0.log", Time: Tue Jan 13 10:45:05 2004 (==) Using config file: "/etc/X11/XF86Config-4" (==) ServerLayout "Default Layout" (**) |-->Screen "Default Screen" (0) (**) | |-->Monitor "Generic Monitor" (**) | |-->Device "Generic Video Card" (**) |-->Input Device "Generic Keyboard" (**) Option "XkbRules" "xfree86" (**) XKB: rules: "xfree86" (**) Option "XkbModel" "pc105" (**) XKB: model: "pc105" (**) Option "XkbLayout" "fr" (**) XKB: layout: "fr" (==) Keyboard: CustomKeycode disabled (**) |-->Input Device "Configured Mouse" (**) |-->Input Device "Generic Mouse" (WW) The directory "/usr/lib/X11/fonts/CID" does not exist. Entry deleted from font path. (**) FontPath set to "unix/:7100,/usr/lib/X11/fonts/Type1,/usr/lib/X11/fonts/Speedo,/usr/lib/X11/fonts/misc,/usr/lib/X11/fonts/cyrillic,/usr/lib/X11/fonts/100dpi,/usr/lib/X11/fonts/75dpi" (==) RgbPath set to "/usr/X11R6/lib/X11/rgb" (==) ModulePath set to "/usr/X11R6/lib/modules" (--) using VT number 7 (WW) Open APM failed (/dev/apm_bios) (No such file or directory) (II) Module ABI versions: XFree86 ANSI C Emulation: 0.2 XFree86 Video Driver: 0.6 XFree86 XInput driver : 0.4 XFree86 Server Extension : 0.2 XFree86 Font Renderer : 0.4 (II) Loader running on linux (II) LoadModule: "bitmap" (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor="The XFree86 Project" compiled for 4.3.0.1, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.4 (II) Loading font Bitmap (II) LoadModule: "pcidata" (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor="The XFree86 Project" compiled for 4.3.0.1, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.6 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 11ab,6460 card 0020, rev 03 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 1106,3044 card 1106,3044 rev 46 class 0c,00,10 hdr 00 (II) PCI: 00:05:0: chip 1000,
Re: How can we XGI share our Linux 2D driver with the open source community? Thanx
On Mon, Jan 12, 2004 at 08:22:50AM -0800, Alex Deucher wrote: > Thank you for producing an opensource driver! Any possibility of a > open source 3D driver down the road? even a "lite" version? Notice that this will give you an edge in todays conpetence, since neither NVidia nor ATI provide open source 3D drivers. If XGI was to release this, i can predict that the XGI cards may well become the graphic cards of choice of many Linux users (as well as other OSes supporting the DRI). Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: How can we XGI share our Linux 2D driver with the open source community? Thanx
Yes. We have done some optimization for h/w acceleration RENDER implementation but not including all aspects of our h/w. Also I think we can improve the 2D performance with the help of the buddy in open source community. Thanx. bst.,rgds Yukun -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexander Shopov Sent: Tuesday, January 13, 2004 3:55 PM To: [EMAIL PROTECTED] Subject: Re: How can we XGI share our Linux 2D driver with the open source community? Thanx Yukun Chen wrote: > For the sake of company policy, now we have no plan to share our 3D > source code. That is not such a big problem. Still - if you want to make your cards a *big* success in open source world, share the 2d part and make sure that you have a hardware accelerated RENDER implementation (or if you cannot do this, share the specifications and documentation. Somebody will take care of the rest.) Accelerated RENDER will make your cards the fastest 2d solution for open source. ( Faster than nVidia and ATi). And this is a lucrative position given the corporate and SOHO markets that are expected to migrate to GNU/Linux (or *BSD) sooner than the home market. 3d is different thing. Some documentation will be always welcome, and if you need specialists under NDA, there will be some that will answer. Best regards: al_shopov > > Thanx. > > Yukun > > -Original Message- > From: Alex Deucher [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 13, 2004 12:23 AM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: How can we XGI share our Linux 2D driver with the open > source community? Thanx > > > Thank you for producing an opensource driver! Any possibility of a > open source 3D driver down the road? even a "lite" version? > > Welcome to the Community! > > Alex > > --- Yukun Chen <[EMAIL PROTECTED]> wrote: > >>Hi All >> >> I am a developer from XGI Technology which is a new company stem > > >>from graphic dpt. of Trident and graphic dpt. of Sis. Now we want to >>share our linux 2D driver with open >> >>source community. Then what should we do? Pls give some advice or >>suggestions. >> >> Thanx a lot. >> >>Bst.,rgds >> >>Yukun,Chen >> >> >>___ >>Devel mailing list >>[EMAIL PROTECTED] >>http://XFree86.Org/mailman/listinfo/devel > > > > __ > Do you Yahoo!? > Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes > http://hotjobs.sweepstakes.yahoo.com/signingbonus > > ___ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel > > ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: How can we XGI share our Linux 2D driver with the open source community? Thanx
Yukun Chen wrote: For the sake of company policy, now we have no plan to share our 3D source code. That is not such a big problem. Still - if you want to make your cards a *big* success in open source world, share the 2d part and make sure that you have a hardware accelerated RENDER implementation (or if you cannot do this, share the specifications and documentation. Somebody will take care of the rest.) Accelerated RENDER will make your cards the fastest 2d solution for open source. ( Faster than nVidia and ATi). And this is a lucrative position given the corporate and SOHO markets that are expected to migrate to GNU/Linux (or *BSD) sooner than the home market. 3d is different thing. Some documentation will be always welcome, and if you need specialists under NDA, there will be some that will answer. Best regards: al_shopov Thanx. Yukun -Original Message- From: Alex Deucher [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 13, 2004 12:23 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: How can we XGI share our Linux 2D driver with the open source community? Thanx Thank you for producing an opensource driver! Any possibility of a open source 3D driver down the road? even a "lite" version? Welcome to the Community! Alex --- Yukun Chen <[EMAIL PROTECTED]> wrote: Hi All I am a developer from XGI Technology which is a new company stem from graphic dpt. of Trident and graphic dpt. of Sis. Now we want to share our linux 2D driver with open source community. Then what should we do? Pls give some advice or suggestions. Thanx a lot. Bst.,rgds Yukun,Chen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel __ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
