Re: (patch seq: 6202) XFree86-4.4.0 -- IPv6 support causes serious problems
On Thu, 1 Apr 2004, Marc Aurele La France wrote: On Thu, 1 Apr 2004, Peter Breitenlohner wrote: 1. thanks for applying these patches (as well as those from patch seq: 6190). When do you expect patches in ftp:/XFree86/4.4.0/fixes/ ? I've no plans to provide any. Few would bother disabling their kernel's IPv6 support. I didn't mean IPv6 in particular, but all the patches/fixes accumulated so far. Have you tried my suggestion regarding this kludge, as you call it? Which suggestion? I didn't see any, but maybe your mail was lost between all the spam I got (in spite of filtering). Could you please resend the suggestion. Peter ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Vesa Driver Probe
...and it shouldn't be hard to implement. Just that most of us have more urgent things on their agenda --- Like removing the XFree86 trademark from the X.org release branch? Ok. Gee ___ Join Excite! - http://www.excite.com The most personalized portal on the Web! ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: (patch seq: 6202) XFree86-4.4.0 -- IPv6 support causes serious problems
Marc Aurele La France wrote: On Mon, 22 Mar 2004, Peter Breitenlohner wrote: It seems that originally there were plans to have two distinct sockets that were abandonned in the middle. Maybe that ought to be cleaned up (fairly trivial mods in xdmcp.c, just excise chooserFd6). Since Alan Coopersmith originally implemented this on Solaris, which can handle both IPv6 and IPv4 on the same socket, there was initially only one socket. As you might know, IPv4 addresses mapped in IPv6 are considered by a potential security problem and are disabled by default in some of the *BSD systems. (I can't repost the link to Itojun's papers on this later). For now IPv6 support for xdmcp is disabled on the hosts that don't support mapped v4 addresses. I started to implement something with 2 sockets for xdmcp, but it turned out to be too much modifications for the XFree86 code freeze (which lasted longer than I expected). It is possible that some of the ChooserFd6 code present here splipped through some of my other fixes for xdm. I think it would be better to keep the chooserFd's separate, i.e. change socket.c. My reasoning is that some systems don't allow IPv4 traffic with an IPv6 socket, i.e. IPv6 is treated as a seperate protocol, rather than a superset of IPv4. Yes I think that too. But the changes to the control flow of xdm are pretty invasive to support that. It's on my todo list for the next weeks when (hopefully) I'll have some more time to spend on X hacking. Another issue is that the XDM-AUTHORIZATION-1 protocol cannot support. A new revision XDM-AUTHORIZATION-2 has been designed by X.Org but no one has implemented it yet. Althrough XDM-AUTHORIZATION-1 is not built by default by XFree86, it provides some enhancements to the security of remote X connections. -- Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
function definition isn't a prototype
From a March 31 CVS update, there are 2714 of the above warnings in a make World when compiling under FreeBSD 5.2 on an Alpha. With some guidance from the committers, I'd like to take on the task of eliminating the vast majority of these. I'll provide context diffs and submit them to the bug tracker as time permits, but I'd like to know whe- ther you feel that the declarations in question should be wrapped in some- thing like #ifdef __STDC__ / #endif or not first. (Or if you'd rather I didn't bother, I'll just shut up and go away :-). Thanks. Terry R. Friedrichsen [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: function definition isn't a prototype
On Fri, 2 Apr 2004, Terry R. Friedrichsen wrote: From a March 31 CVS update, there are 2714 of the above warnings in a make World when compiling under FreeBSD 5.2 on an Alpha. With some guidance from the committers, I'd like to take on the task of eliminating the vast majority of these. I'll provide context diffs and submit them to the bug tracker as time permits, but I'd like to know whe- ther you feel that the declarations in question should be wrapped in some- thing like #ifdef __STDC__ / #endif or not first. No, please don't wrap them. Support for pre-ANSIC compilers is pretty much dead now. (Or if you'd rather I didn't bother, I'll just shut up and go away :-). Please wait a bit, as I still have a few such things to integrate. Also, I'd prefer you sent them to me directly. Thanks. 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
Re: function definition isn't a prototype
On Fri, 2 Apr 2004, Terry R. Friedrichsen wrote: From a March 31 CVS update, there are 2714 of the above warnings in a make World when compiling under FreeBSD 5.2 on an Alpha. With some guidance from the committers, I'd like to take on the task of eliminating the vast majority of these. I'll provide context diffs and submit them to the bug tracker as time permits, but I'd like to know whe- ther you feel that the declarations in question should be wrapped in some- thing like #ifdef __STDC__ / #endif or not first. I'm not a committer, just someone who has been around long enough to remember the discussions about ansifying the code. I don't think we need #ifdef __STDC__ or similar. The ansification work is progressing very slowly because we need to be sure that we don't change the types of any arguements when we do this - remember that the default type promotions rules changed between KR and ANSI C. This means that the could be binary incompatibilities in the interfaces we we do this with a dummy script, rather than a thinking brain. Thomas Dickey has done bits in the past, and has email suggestions about how to verify that binary compatibility isn't broken. Thanks for offering to help. -- 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: function definition isn't a prototype
On Fri, 2 Apr 2004, Terry R. Friedrichsen wrote: From a March 31 CVS update, there are 2714 of the above warnings in a make World when compiling under FreeBSD 5.2 on an Alpha. With some guidance from the committers, I'd like to take on the task of eliminating the vast majority of these. I'll provide context diffs and submit them to the bug tracker as time permits, but I'd like to know whe- ther you feel that the declarations in question should be wrapped in some- thing like #ifdef __STDC__ / #endif or not first. See http://invisible-island.net/ansification/ for example. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: function definition isn't a prototype
On Fri, 2 Apr 2004, Dr Andrew C Aitchison wrote: On Fri, 2 Apr 2004, Terry R. Friedrichsen wrote: From a March 31 CVS update, there are 2714 of the above warnings in a make World when compiling under FreeBSD 5.2 on an Alpha. With some guidance from the committers, I'd like to take on the task of eliminating the vast majority of these. I'll provide context diffs and submit them to the bug tracker as time permits, but I'd like to know whe- ther you feel that the declarations in question should be wrapped in some- thing like #ifdef __STDC__ / #endif or not first. I'm not a committer, just someone who has been around long enough to remember the discussions about ansifying the code. I don't think we need #ifdef __STDC__ or similar. right - what we need are changes that preserve the interfaces (don't change types/sizes) but eliminate the nonstandard syntax. It's time-consuming. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: depth switching on the fly
I totally agree with you that *something* needs to be done to address this defficiency in XFree86. As mentioned in a previous post a while back I am trying to write some 2d games for Linux but require; fullscreen, direct access, vsynching, ability to change the start of display offset (for page flipping and vertcial scrolling), 8 bit indexed palettes, etc... We are left using DGAv2 as it satisfies all these requirements, but it seems most the XFree developers want it removed in the future, with no real replacement :( I am currently starting to write a windowed version of the gfx libs, but it will suck hugely in speed terms compared to that of DGA. People will say why not use OpenGL, but lets face it.. OpenGL sucks for 2d, it is overcomplicated for this task, when all you want to do simple 2d sprite drawing, some palettized effects, and scrolling... On Thu, 1 Apr 2004 18:03:23 -0800 (PST) Luchezar Belev [EMAIL PROTECTED] wrote: hi all, I want to toss an idea about the depth switching on the fly. The dynamic depth changing is one of the few basic things that are impossible in xf86. In fact DGA2 has such ability, but it's limited for it's own use only. The new randr extension in it's full variant can do it but as of now it's not implemented and it seems quite unliky to be implemented ever because from it's design follows that it's implementation would be extremely hard thing to do, and naturally noone feels motivated enough to take up the task. But such functionality is really important if we want xf86 to be considered an viable gaming platform. For example it would be a great benefit for the Wine in it's efforts in emulating windows for games. Some argue that the need of depth switching has been somewhat outweighted by the fact that these days the memory is cheap and noone cares if the framebuffer takes twice as much memory. Of course the memory usage itself does not matter, but what really matters is the speed. For example quake3 does almost twice as many frames per second if run in 16-bit mode than in 32-bit mode. And this cannot be outweighted whatever the memory price is. Even in nowdays many games prefer low-depth modes (sometimes even 8-bit) because of the lower bandwidth requirement, which is critical. Now my idea. Since the main potential users of such functionality are the games, and they are mainly full-screen apps it would be relatively easy but still very usefull if we have something in between the DGA2 and randr - some kind of fullscreen (i.e. only single window visible - no need for software depth emulation for the rest of the windows, etc.) but using real x window so that one can use the standard X11 apis available for the normal windows (for example use GLX/OpenGL with it) For example the api function could be something like: Window Xextension-nameCreateFullscreenWindow( Display *dpy, Xextension-nameModeDescriptor *vidmode, int depth, Visual *visual, unsigned long valuemask, XSetWindowAttributes *attribs ); The function creates a special fullscreen window. When such window get mapped (XMapWindow) it automatically switches the video mode to vidmode and changes the framebuffer depth to the window's depth (which may differ from the root window's depth). Such windows always occupy the entire screen and may not be obscured by other windows (and probably have their override_redirect attribute always set). When the window is unmapped it switches back the video mode and the frame buffer depth to their normal states. The video mode description could probably be something like in the XF86VidMode extension. Lucho __ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
