Re: IPv6 problems on Linux
Marc Aurele La France writes: On Wed, 23 Jul 2003, Egbert Eich wrote: Marc Aurele La France writes: I don't like the peppering of this code with more OS #ifdef's. I think the approach espoused by Itojun, Todd, Matthieu and Andrew is better. So maybe you can tell what the big difference is? So maybe not. I've already stated I cannot test IPv6 function. As such, I'm here more as an overseer, and in that capacity I am of the opinion that this code need not be unnecessarily OS-#ifdef'ed. Take that as you see fit. OK, I've taken out the 'defined (linux)' stuff as I agree with you that it is ugly. I expect the code would work on all other platforms, although I cannot test it. The reason why I left the 'defined (linux)' in there was that platforms that don't have the broken Linux behavior suffer a minor penalty: server 1 started with: X -nolisten inet6 -nolisten unix -nolock :0 server 2 started with: X -nolisten unix :0 -nolock The second server doesn't catch that the first one is already using port 6000 for ipv4 as bind to the ipv4 port fails silently if bind to the ipv6 port was successful. This may be a rare condition, though. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: IPv6 problems on Linux
This 'nolisten' code was added on 1996/11/24 with revision 3.22.
The cvs log only says:
revision 3.22
date: 1996/11/24 09:58:50; author: dawes; state: Exp; lines: +14 -1
updates
I would assume it was taken straight from a SI merge.
Alan Coopersmith writes:
Maybe I'm missing something, but I always thought the XFree86 nolisten
code was overly complicated, and this just seems to make it worse. When
we added -nolisten to Xsun, we got multiple listeners for free with a
simpler implementation, contained entirely in utils.c:
else if ( strcmp( argv[i], -nolisten) == 0)
{
if(++i argc) {
if (_XSERVTransNoListen(argv[i])) {
FatalError (Failed to disable listen for %s transport,
argv[i]);
}
} else
UseMsg();
}
I have made a patch similar to Matthieu's but this looks much simpler
:-}
Does anybody know why we use this complicated approach?
Egbert.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Rant (was Re: ATI Drivers.)
On Sun, Jul 20, 2003 at 02:22:10AM -0400, Mike A. Harris wrote: I have no problem for them to go proprietary, but i would very much like a powerpc version of said drivers. Since both of them also release drivers for MacOSX, i guess this would not be very expensive to just rebuild powerpc versions of them. Or for other arches too. I think this is the cost the graphic companies have to pay for not releasing the source code. Perhaps if said companies business and marketing departments determine that producing PPC drivers will be in the best interests of their stockholders, they might decide to book engineering resources to produce PPC drivers. The lack of such drivers would indicate to me that there is not enough revenue predicted to be generated by allocating such resources that such drivers are more cost to develop than any financial gains received by doing so. I'm no financial analyst by any stretch of the imagination. Running a publically traded company on a charity basis however is a good way to upset stockholders. Another issue is if those drivers are in the least flaky, then you get very bad press for having dodgy drivers, so you're going to either have to dedicate heaps of resources, or none at all. I know what I'd be gunning for, if I had a BComm, or whatever. Try putting the engine of a Japanese car into an American made car. Then complain to Nissan that it doesn't work, and see how far you get. Nissan did make the V8 engine for the Holden VL Commodore, a typical Australian grunt car. :) If anything they'd likely get sued by 3rd party vendors whom they've licensed code and/or patented technology from, which they do not have the right to give away to the public. That includes both software, and hardware interfaces as well. Only the particular hardware vendor in question knows what IP they have in their hardware and drivers, and what they can do with that IP legally. Yep, and this goes quite deep: apparently they can't even release TV-Out specs, for fear of getting smacked down by Macrovision. You're really asking Kentucky Fried Chicken, to give the recipe for their 11 herbs and spices here, and the secret sauce. Pretty soon, half of the KFC customers have no need to go to KFC as they can make it at home. And McDonald's start selling Alabama Fried Chicken, so you can go to the one place for all your burger and chicken needs. Bzt. By the way, I have a recipe for chicken that legal jargon tastes very similar to, but is not KFC. I wonder if someone let the cat out of the bag at KFC one day, and this is the Colonel's secret recipe? I've got this black syrupy stuff that tastes just like Coke, too! Who knows. The chances of reverse engineering the kernel microcode engine from one of these drivers however is even much more likely than reverse engineering the KFC recipe by analyzing the molecular structure of the crispy crust. Aye. The problem with this view is that most people slam you for trying to kill open source or some crap, when you're being realistic. -- Daniel Stone [EMAIL PROTECTED] http://www.kde.org - http://www.debian.org - http://www.xwin.org Configurability is always the best choice when it's pretty simple to implement -- Havoc Pennington, gnome-list pgp0.pgp Description: PGP signature
Re: Rant (was Re: ATI Drivers.)
On Sun, Jul 20, 2003 at 05:12:00AM -0400, Mike A. Harris wrote: On Sat, 19 Jul 2003, Daniel Stone wrote: Not very many, and their competitirs would then have access to all their IP, so could out-do them in the next generation of cards. I doubt that it would involve hardware as much as it would involve the driver aspect and the JIT compiler for the GPU perhaps. Having never seen the complete source code of any modern proprietary full featured video driver however, it's very hard to say. Well, not all, but AIUI it's becoming less of a pure hardware situation, and more of intelligent software being required, and sort of showing your hand, so to speak. Then again, I'm *way* out of my depth here, so I'm likely to be way off the mark. I think Mark would probably be the most qualified to speak about this. ;) -- Daniel Stone [EMAIL PROTECTED] http://www.kde.org - http://www.debian.org - http://www.xwin.org Configurability is always the best choice when it's pretty simple to implement -- Havoc Pennington, gnome-list pgp0.pgp Description: PGP signature
Hardware overlays (8+24?) on Intel i830
I see from http://www.xig.com/Pages/PrReleases/PRMay03-830-O'lays.pdf that hardware overlays (possibly similar to what we currently do in the mga and glint drivers) are possible on the Intel i830 chipset. Does anyone know anything more, or is anyone actually working on adding support to our drivers ? If anyone with a suitable machine is interested in testing for me, and I can get chip-level details, I *might* be interested in writing the code myself. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: IPv6 problems on Linux
Hmm, with the current approach a -nolisten to an alias has no effect anyway. A '-nolisten tcp' will have the same effect as a '-nolisten unix': None. The reason is that a flag is set for the protocol however when the protocols are initialized the aliases aren't checked. Also tcp is aliased to IPv6. I don't know why this was done but I would expect that it violates the principle of least surprise: When connecting with 'display tcp/1.2.3.4:0' a IPv6 socket is created and the IPv4 connection is done over the IPv6 socket. This may not work on systems without IPv6 support. Egbert. Keith Packard writes: Around 23 o'clock on Jul 23, Matthieu Herrb wrote: Here's a patch to allow multiple '-nolisten' options on the command line. To disable both IPv4 and IPv6 transports, one needs to say: X -nolisten tcp -nolisten inet6 While supporting multiple -nolisten arguments is good, I suggest that the current '-nolisten tcp' should include both inet4 and inet6 tcp options; most people use '-nolisten tcp' to avoid exposing an open port to the X server to the network. -nolisten inet4 don't listen for TCP/IPv4 connections -nolisten inet6 don't listen for TCP/IPv6 connections -nolisten tcp don't listen for any TCP connections -keith ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: IPv6 problems on Linux
Andrew C Aitchison writes: Egbert's latest patch compiles and runs, but it isn't addressing my problem. This is with Red Hat 8.0 Linux 2.4.20-19.8 gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7) (I have the same problem with Red Hat 6.2). The system is *not* configured with IPv6, and socket(PF_INET6, SOCK_STREAM, 0) fails with -1 EAFNOSUPPORT (Address family not supported by protocol). This is not unexpected, but how are we supposed to carry on and try PF_INET ? Thus xbiff -display inet/localhost:10 works (I'm connecting over ssh), but xbiff -display localhost:10 fails reporting _X11TransSocketOpen: socket() failed for tcp _X11TransSocketOpenCOTSClient: Unable to open socket for tcp _X11TransOpen: transport open failed for tcp/localhost:10 Error: Can't open display: localhost:10 That's what I've explained in my previous message. Can we just declare that inet and inet6 both match tcp ? The way the code is currently written aliases like tcp alias to exactly one transport type. There is no fallback mechanism. The easiest way would be to alias tcp to inet instead of inet6. Or somebody designes a fallback mechansim. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: IPv6 problems on Linux
Egbert Eich wrote: This 'nolisten' code was added on 1996/11/24 with revision 3.22. The cvs log only says: revision 3.22 date: 1996/11/24 09:58:50; author: dawes; state: Exp; lines: +14 -1 updates I would assume it was taken straight from a SI merge. The SI doesn't have the -nolisten option. (Probably should, but never got it added. We took the code from XFree86 when integrating into Xsun, except for the previously noted change in the option handling.) -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - Sun Software Group Quality / User Experience (QUE) - Globalization Platform Globalization Engineering: X11 Development ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
CT 69030flags
Hello everyone!
Can any one please tell me the meaning of all these flags?
These relate to CT VGA driver in XFree86 code.
Iam writing the driver for CT 69030.
/* Architecture type flags */
#define ChipsHiQV 0x0001
#define ChipsWingine 0x0002
#define IS_Wingine(x) ((x-Flags) ChipsWingine)
#define IS_HiQV(x) ((x-Flags) ChipsHiQV)
Thanking u all in advance,
regards,
Nitin
Iç[É'º·Êw«%b®ër·'«¾' üZ+wè®få¢'¶á¶Úÿÿü0Ãû rê)
¨X§{÷(á¶Úÿÿü0Ãû rê) ÿ
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: IPv6 problems on Linux
On Thu, 24 Jul 2003, Egbert Eich wrote: Can we just declare that inet and inet6 both match tcp ? The way the code is currently written aliases like tcp alias to exactly one transport type. There is no fallback mechanism. The easiest way would be to alias tcp to inet instead of inet6. Agreed. That will at least give us backwards compatibility. inet6 is new; people using it can cope with asking for it explicitly. Or somebody designes a fallback mechansim. When we release XFree86 4.4 or 5.0 we need machinename:display to work on any appropriate transport protocol (probably tcp/ as it is now) and tcp/machinename:display to work for inet/ and inet6/ -nolisten tcp should block inet and inet6. --- Aside: Which operating systems are shipping with IPv6 enabled by default ? -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: IPv6 problems on Linux
On Thu, Jul 24, 2003 at 04:30:47PM +0100, Dr Andrew C Aitchison wrote: Which operating systems are shipping with IPv6 enabled by default ? NetBSD has IPv6 enable by default, Solaris hasn't. Kind regards -- Matthias Scheler http://scheler.de/~matthias/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: IPv6 problems on Linux
Matthias Scheler wrote: On Thu, Jul 24, 2003 at 04:30:47PM +0100, Dr Andrew C Aitchison wrote: Which operating systems are shipping with IPv6 enabled by default ? NetBSD has IPv6 enable by default, Solaris hasn't. Solaris sort of does - on Solaris 8 and later, you can always use an AF_INET6 socket to connect to an IPv4 address. If you ifconfig an IPv6 interface you can use that as well. The original X.org IPv6 patches came directly from the IPv6 code in the Solaris 9 X distribution which uses AF_INET6 for all IPv4 or IPv6 connections. Unlike Linux the BSD's, you can't remove AF_INET6 support since we don't provide kernel source for recompiling your own. -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - Sun Software Group Quality / User Experience (QUE) - Globalization Platform Globalization Engineering: X11 Development ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
patch procedure ..
sorry for being lazy and not RTFM, but after i send a patch to the patch email addy, and i have received an acknowledge .. - how long does it takes to get an answer - usually - will it happen to get no answer at all ? thx for any reply sven ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Rant (was Re: ATI Drivers.)
On Wed, Jul 23, 2003 at 04:42:31PM -0700, Kendall Bennett wrote: Jon Leech [EMAIL PROTECTED] wrote: I'll back that up. Besides which, after a few years of being bitched at (and in one case involving a friend who's a senior software engineer at a commodity graphics vendor, physically threatened) because their company wasn't doing enough for Linux/OSS, I know a number of folks in industry who have moved well away from their initial pro-Linux/OSS position. It would be foolish to think that the personal views of important individuals inside a company do not have an effect on that company's official policies. It definitely DOES NOT WORK to harangue, Slashdot, or otherwise abuse the people responsible for the product you care about. At best you and others like you will be tuned out in the future. At worst you will be responsible for creating hostility towards you and your needs. There is no upside to this behavior. I agree with that 100%. We actually would have had a release version of our Linux product at least three years ago, except for the massive amount of negative feedback we received during our initial public beta cycle on slashdot etc. Most of the complaints were along the lines of it ain't free, where's the source etc. It left such a bad taste in our mouths that when the original intern working on the project went home, we basically canned the product and only recently got back to working on it again. Thankfully the Linux community seems much more receptive to our products now (but then again we haven't announced anything on slashdot in years ;-). Frankly, your own rants against XFree86 and some of its volunteers recently are no different than this. It sure left a bad taste in our mouths. There is a sickening propensity towards hostile and intimidating behaviour from several quarters, and it deserves the negative results it will surely achieve. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: patch procedure ..
from 24 hours to 7 days depending on complexity and on people having time working on it. -Alex. -Original Message- From: Sven Goethel [mailto:[EMAIL PROTECTED] Sent: Thursday, July 24, 2003 19:17 To: [EMAIL PROTECTED] Subject: patch procedure .. sorry for being lazy and not RTFM, but after i send a patch to the patch email addy, and i have received an acknowledge .. - how long does it takes to get an answer - usually - will it happen to get no answer at all ? thx for any reply sven ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: IPv6 problems on Linux
On Wed, Jul 23, 2003 at 11:34:53PM -0400, Keith Packard wrote: Around 23 o'clock on Jul 23, Matthieu Herrb wrote: Here's a patch to allow multiple '-nolisten' options on the command line. To disable both IPv4 and IPv6 transports, one needs to say: X -nolisten tcp -nolisten inet6 While supporting multiple -nolisten arguments is good, I suggest that the current '-nolisten tcp' should include both inet4 and inet6 tcp options; most people use '-nolisten tcp' to avoid exposing an open port to the X server to the network. -nolisten inet4 don't listen for TCP/IPv4 connections -nolisten inet6 don't listen for TCP/IPv6 connections -nolisten tcp don't listen for any TCP connections Yes, the generic option should disable all TCP transport types. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Rotating the desktop
To whom it may concern, I'm not sure if this is the right place to ask, but is this feature planned for the next release (4.44)? Is it being worked on? If so who do I need to talk to in order to best assist in its development? Thanks Gareth.
Re: Rant (was Re: ATI Drivers.)
David Dawes [EMAIL PROTECTED] wrote: Frankly, your own rants against XFree86 and some of its volunteers recently are no different than this. It sure left a bad taste in our mouths. There is a sickening propensity towards hostile and intimidating behaviour from several quarters, and it deserves the negative results it will surely achieve. Excuse me!? My own rants against XFree86 and some of its volunteers?? When exactly have I 'ranted' against XFree86 and some of it's volunteers? Thank you, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Rant (was Re: ATI Drivers.)
David Dawes [EMAIL PROTECTED] wrote: Frankly, your own rants against XFree86 and some of its volunteers recently are no different than this. It sure left a bad taste in our mouths. There is a sickening propensity towards hostile and intimidating behaviour from several quarters, and it deserves the negative results it will surely achieve. I have still yet to receive an email from you either backing up your claims that I have been ranting against XFree86 and some it's volunteers recently. Either back it up or offer me an apology. This kind of behaviour is simply not acceptable from the 'impartial' leader of XFree86. BTW, congrats on your new company X-Oz (http://www.x-oz.com/). I wish you luck developing proprietry versions of XFree86 including your 'greatly improved version of the XFree86 loader'. Thank you, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: Hardware overlays (8+24?) on Intel i830
Yes, The Mobile chipsets could do this under several circumstances. The desktop chips cannot. Could you provide an indication of what such a feature is actually useful for? It seems like more of a toy feature than something with real world applications. Seems like you could actually run at 24bpp and convert from 8 to 24 in the driver with less performance impact than running an additional display plane that consumes width*height*depth*refresh bytes per second guaranteed. -Matt -Original Message- From: Dr Andrew C Aitchison [mailto:[EMAIL PROTECTED] Sent: Thursday, July 24, 2003 5:09 AM To: [EMAIL PROTECTED] Subject: Hardware overlays (8+24?) on Intel i830 I see from http://www.xig.com/Pages/PrReleases/PRMay03-830-O'lays.pdf that hardware overlays (possibly similar to what we currently do in the mga and glint drivers) are possible on the Intel i830 chipset. Does anyone know anything more, or is anyone actually working on adding support to our drivers ? If anyone with a suitable machine is interested in testing for me, and I can get chip-level details, I *might* be interested in writing the code myself. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: Rotating the desktop
Just to add to this: I was looking at this the other day and along with native rotated rendering to the framebuffer it would be nice if the ShadowFB could indicate that it is capable of doing the rotation too. i.e. When rotation is requested from the config or RandR Option 1: If the hardware can just display a rotated image then just render normally and let the driver handle the rotation. Option 2: If the driver is using ShadowFB and the ShadowFB indicates that it can rotate in the back-front blit then render normally and let ShadowFB handle the rotation. Option 3: If no ShadowFB support and No Driver support then render natively rotated. -Original Message- From: Gareth [mailto:[EMAIL PROTECTED] Sent: Thursday, July 24, 2003 11:11 AM To: [EMAIL PROTECTED] Subject: Rotating the desktop To whom it may concern, I'm not sure if this is the right place to ask, but is this feature planned for the next release (4.44)? Is it being worked on? If so who do I need to talk to in order to best assist in its development? Thanks Gareth. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
